problem with scandir

[Brendan Eich]

In article <1991Mar27.163133.19962 at odin.corp.sgi.com>, jwag at moose.asd.sgi.com (Chris Wagner) writes:
> In article <1991Mar25.191630.939 at cs.ruu.nl>, markov at cs.ruu.nl (Mark
> Overmars) writes:
> > I have a problem with the routine scandir. After some stripping I came
> up with
> > the following program: [...]
> > It dumps core. It does not do so for any other directory than /bin.
> > (Same behaviour on two unrelated machines.) Any reason why and any
> suggestions
> > how to solve it?
> 
> THis is a bug in scandir in 3.3 - having to do with how much memory
> scandir will allocate to hold the directory entries. It gueses based on the
> stat size of the directory using a heuristic designed for BSD FFS which
> doesn't always work on EFS. If you simply add another entry to /bin it
> will probably start working.
> 
> It has been fixed in 4.0

In the mean time, if you #include <sys/dir.h> instead of <dirent.h>, you'll
get the BSD-compatible directory(3B) interface.  Calling scandir after you
include <sys/dir.h> compiles a call to BSDscandir, which (because it uses
those pesky BSD FFS directory entry structures) guesses the right size for
the array of entries that it allocates.  If there's a bug with BSDscandir,
please let us know.  But it *should* work just like on a 4.3 system.

The System V and Berkeley directory(3) interfaces are so similar, the only
differences among structs dirent (SysV) and direct (BSD), other than the
struct tag names, are the meaning of d_reclen, the absence of d_namlen in
System V's dirent (a botch), and the absence of the next entry's "offset"
cookie, d_off, in the BSD struct direct (another botch).

/be