Dave Korn wrote:
> Ben Hutchings wrote:
<snip> 
> > In some versions of Tcl (8.4.2 to 8.5a2 inclusive), the dimension of the
> > name field is MAXNAMLEN+1, not PATH_MAX+1.
> 
>   The code I quoted was from /src, which hasn't had a new version merged in
> from upstream recently and is still on 8.4.1.

Good; I've updated the advisory to state that there is no problem when
using the included version of Tcl.

<snip> 
> > <snip>
> >>   I'm with Zaraza (sp?) on this one.  What's wrong with statically
> >> sizing it to NAME_MAX+1, in accordance with the demands of the posix
> >> spec? <snip> 
> > 
> > NAME_MAX isn't required to be defined (and MAXNAMLEN isn't even
> > mentioned by POSIX, though it is equivalent on many systems).  
> 
>   Oh well, autoconf can help with that, as could falling back to PATH_MAX if
> it exists.  In practice, it doesn't seem to really be an issue: the use of
> PATH_MAX in that structure is unconditional and in fact not autoconfiscated,
> and nobody has reported that they've had trouble building for lack of it.

While this seems to me to be a poor way of determining the buffer size,
in practice it is likely to be safe.

> > GNU/Hurd
> > doesn't define it, for example, because there is no practical limit on
> > name lengths there.
> 
>   Umm, then surely GNU/Hurd is insane and cannot be used because there is no
> way to ever know how much space to allocate for a dirent?

No, that's what pathconf is for.  Most systems that define NAME_MAX are
not POSIX-compliant in this respect because they support filesystems
that have name length limits differing from whatever value they specify.

Please see the sample code for a dirent_buf_size function in revision 2
of the advisory at
<http://womble.decadentplace.org.uk/readdir_r-advisory.html>.

Ben.

-- 
Ben Hutchings
When you say `I wrote a program that crashed Windows', people just stare ...
and say `Hey, I got those with the system, *for free*'. - Linus Torvalds