The following reply was made to PR lib/43310; it has been noted by GNATS.
From: David Holland <[email protected]>
To: [email protected]
Subject: Re: lib/43310: dirent(5) standard compliance
Date: Sat, 15 May 2010 19:38:42 +0000
On Sat, May 15, 2010 at 03:10:06PM +0000, Jukka Ruohonen wrote:
> > Why not change NAME_MAX?
> That is one possibility, yes.
NAME_MAX and MAXNAMLEN are supposed to correspond, same as PATH_MAX
and MAXPATHLEN, so it was a bug to update one and not the other.
(Ideally, the old MAX*LEN constants would go away in favor of the
equivalent POSIX ones, but that's a long way off.)
It would probably be a good idea to do a quick grep in the kernel to
make sure that changing NAME_MAX won't result in stack overflows.
There are quite a few on-stack uses of char[NAME_MAX], mostly
indirectly via EXTATTR_MAXNAMELEN and XATTR_NAME_MAX (why do both of
those exist?) and the use via MQ_NAMELEN in sys/mqueue.h probably
requires a kernel version bump.
> As for the other issue, I am not entirely sure anymore whether what I wrote
> makes sense in terms of portability. (Provided that the fixed size array
> does not prompt someone to, say, apply sizeof() instead strlen() to d_name,
> provided that d_namlen is not standardized.)
The parts of the structure that don't include the name string are a
header on each name, which is of non-fixed length. It is an error to
increment a struct dirent pointer. (See _DIRENT_NEXT in sys/dirent.h.)
However, the only people who need to know that are filesystem and libc
implementors, who are supposed to more or less know what they're
doing; ordinary people using readdir(3) aren't exposed to this.
Changing to the declaration glibc uses (with the zero-length array at
the end) might be desirable; that usage is now blessed by the C
standard. (This should probably also be done in the ffs code, but
that's a separate problem.)
David A. Holland