Bugtraq mailing list archives
Re: strcpy versus strncpy
From: mouse () RODENTS MONTREAL QC CA (der Mouse)
Date: Thu, 5 Mar 1998 10:05:24 -0500
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. The documentation for 4.3 claimed there was a hard limit MAXPATHLEN on the total length of a pathname - AFAICR I never verified this. But I just looked at the NetBSD source and it (and by implication, probably 4.4 and almost all derivatives thereof) imposes a similar hard maximum, again MAXPATHLEN (though I don't know whether the value differs between 4.3 and 4.4/NetBSD/etc). (Those of you who wish to verify this claim for yourselves should look at namei(), in sys/kern/vfs_lookup.c, and note the copystr/copyinstr call with an explicit MAXPATHLEN limit. The version of vfs_lookup.c I'm looking at is 1.24.2.1; I believe this is the 1.3 release version.) In the NetBSD source tree I have handy, MAXPATHLEN is defined in <sys/param.h> as PATH_MAX; PATH_MAX is defined in <sys/syslimits.h> as 1024. The limit of 255 on a path component length probably originally came from the directory format, which reserves only one byte to store that length; it is also imposed (for all filesystems, not just FFS) by lookup(), also in vfs_lookup.c, which explicitly checks if (cnp->cn_namelen > NAME_MAX) { error = ENAMETOOLONG; goto bad; } I also note the presence of _PC_PATH_MAX and _PC_NAME_MAX in the pathconf() manpage. The manpage claims POSIX compliance, and I thus have reason to think POSIX defines those, though I do not have a copy of POSIX handy to check. But there is a strong implication that POSIX expects such limits to exist (otherwise, why provide a way to query them?), and if you can demonstrate the existence of anything even vaguely UNIXish that does not impose hard and relatively small limits on path and name length I would love to hear about it.
PATH_MAX (and friends) under Unix is a lower bound on the length of a name that the system is required to support under all circumstances.
What is your authority for this statement? The only documentation I have found on what PATH_MAX is is the comment in <sys/syslimits.h>, which says simply "max bytes in pathname".
But there are facilities that work with any length of name that they are supplied with.
Please give an example. (The example must, of course, use the string as a pathname; calls such a strcpy() that manipulate strings without treating them as pathnames are irrelevant here.) der Mouse mouse () rodents montreal qc ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Current thread:
- Re: strcpy versus strncpy, (continued)
- Re: strcpy versus strncpy Mark Whitis (Mar 04)
- Re: strcpy versus strncpy Andy Church (Mar 02)
- Re: strcpy versus strncpy Edwin Li-Kai Liu (Mar 03)
- Re: strcpy versus strncpy Ben Laurie (Mar 03)
- Re: strcpy versus strncpy Chris L. Mason (Mar 03)
- Re: strcpy versus strncpy der Mouse (Mar 04)
- Re: strcpy versus strncpy Aleph One (Mar 04)
- Re: strcpy versus strncpy Aleph One (Mar 04)
- Re: strcpy versus strncpy Aleph One (Mar 04)
- Re: strcpy versus strncpy Aleph One (Mar 04)
- Re: strcpy versus strncpy der Mouse (Mar 05)
- Re: strcpy versus strncpy Nick Maclaren (Mar 05)
- Re: strcpy versus strncpy Steve Bellovin (Mar 05)
- Re: strcpy versus strncpy Paul McNabb (Mar 05)