Re: strcpy versus strncpy

[mouse () RODENTS MONTREAL QC CA (der Mouse)]

> > 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