Re: lib/43310: dirent(5) standard compliance

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR lib/43310; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
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
 dholland%netbsd.org@localhost