Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!sgi!brendan@illyria.wpd.sgi.com
From: brendan@illyria.wpd.sgi.com (Brendan Eich)
Newsgroups: comp.sys.sgi
Subject: Re: problem with scandir
Summary: Workaround: BSDscandir
Keywords: dumps core
Message-ID: <93927@sgi.sgi.com>
Date: 27 Mar 91 19:10:14 GMT
References: <1991Mar25.191630.939@cs.ruu.nl> <1991Mar27.163133.19962@odin.corp.sgi.com>
Sender: guest@sgi.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 33

In article <1991Mar27.163133.19962@odin.corp.sgi.com>, jwag@moose.asd.sgi.com (Chris Wagner) writes:
> In article <1991Mar25.191630.939@cs.ruu.nl>, markov@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