|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Re: strcpy versus strncpy
Paul McNabb (mcnabb
ARGUS-SYSTEMS.COM)Thu, 5 Mar 1998 14:33:26 -0600
- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Wietse Venema: "dynamic memory allocation considered beneficial"
- Previous message: Theo de Raadt: "New OpenBSD security web page"
- Maybe in reply to: Morten Welinder: "strcpy versus strncpy"
> From: der Mouse <mouseRODENTS.MONTREAL.QC.CA> > > >> In your specific example of a file name, most (all?) operating > >> systems already impose a limit to the length of a file name. > > I am sorry, but this this is complete and utter nonsense. MVS is one > > of the few systems that does impose such a limit and, even then, the > > limit is not as obvious as might appear. Unix has NO limit, and > > never has had. > > I suggest you check your facts. > > "file name" can mean (at least) two things: a directory entry (ie, a > single link in the filesystem tree) or an entire path name. > > The former has always had a hard limit and likely always will. This > limit used to be (IIRC) 14 bytes under V7 and older SysV; FFS raised > this to 255. I have never seen it higher than 256; if you know of a > UNIX-alike with this limit higher than 255 I would love to hear full > details. Actually, there are two issues here. It is true that all Unix systems I know of actually impose a maximum path length. But this limit is only imposed on the string passed to the kernel in a system call. But the "true path length" of a file, that is, the "/" separated list of all directories from the root directory down to the file, is limited only by the number of inodes in the file system. The system will allow you to use "." as the first element of a path, and you can follow it with a string up to the kernel limit. It is possible that a program could create a very deep directory tree, with the root of that tree itself sitting a hundred directories deep from the file system root. The files could all be handled properly by the kernel if the program referenced files in system calls using a relative path name. Internally, however, the program may have stored an absolute path name that could exceed the system limit. paul --------------------------------------------------------- Paul McNabb Argus Systems Group, Inc. Vice President and CTO 1809 Woodfield Drive mcnabb
argus-systems.com Savoy, IL 61874 USA TEL 217-355-6308 FAX 217-355-1433 "Securing the Future" ---------------------------------------------------------
- Next message: Wietse Venema: "dynamic memory allocation considered beneficial"
- Previous message: Theo de Raadt: "New OpenBSD security web page"
- Maybe in reply to: Morten Welinder: "strcpy versus strncpy"