Re: struct dirent in Linux 2.0

Clemens Huebner - Sun Germany Technical Solution Center - Munich (Clemens.Huebner@Germany.Sun.COM)
Wed, 19 Feb 1997 11:30:20 +0100


> From cpage@comp3244.resnet.sjsu.edu Wed Feb 19 11:15:07 1997
> Date: Wed, 19 Feb 1997 01:00:49 -0800 (PST)
> From: Chad Page <cpage@comp3244.resnet.sjsu.edu>
> To: Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
> Cc: Swen Thuemmler <swen@uni-paderborn.de>, "Aaron M. Ucko" <amu@mit.edu>,
linux-kernel@vger.rutgers.edu
> Subject: Re: struct dirent in Linux 2.0
> Mime-Version: 1.0
>
>
>
> On Wed, 19 Feb 1997, Ulrich Windl wrote:
>
> > > Well, my copy of POSIX.1 (1003.1 from 1988) says:
> > >
> > > "The readdir() function returns a pointer to an object of type struct
> > > dirent that includes the member:
> > > Member Type Member Name Description
> > > ----------- ----------- -----------
> > > char[] d_name Null-terminated filename
> > > The character array d_name is of unspecified size, but the number of bytes
> > > preceding the terminating null character shall not exceed {NAME_MAX}."
> > >
> > > So it explicitely states, that d_name is zero-terminated. It mentions no
> > > other members of the dirent structure, so any other member is nonstandard
> > > (but not explicitly forbidden, you may use it, but then your program does
> > > not conform to POSIX.1, I think).
> > >
> > OK, convinced. Unfortunately the description I had did not
> > distinguish what was POSIX, and what was an extension to POSIX.
> >
> One other question - is the address returned by readdir valid only
> until the next readdir for the directory in question, or just the next
> readdir. Basically, what I'm asking is if in the case of Linux/8086,
> where data segement space is tight, can the library code get away with
> allocating just one dirent structure, regardless of the number of
> directories open? If so, it could be implemented rather easily. (Or, in
> worst case, does *each* readdir have to have a different dirent?)
>
> IMHO, the entire readdir() idea dosen't jive well with the core
> UNIX syscalls, since the library returns a pointer, instead of having one
> preinitialized... oh well. (It's impossible to do a pure in-kernel
> implementation of readdir() under ELKS because of this...) Thanks...

>From the Solaris manual page for readdir:
...
The pointer returned by readdir() points to data that may be overwritten by another
call to readdir() on the same directory stream. This data shall not be overwritten
by another call to readdir() on a different directory stream. readdir() may buffer several
directory entries per actual read operation;
...
So we can guess the following about the rules &options (i won't look at the source, since then
i wouldn't be able to talk about this):
- the library HAS to allocate at least 1 struct per directory stream
- for performance reasons the library MAY allocate more structs

NOTE:
Solaris contains a special POSIX readdir call:
POSIX
cc [ flag... ] file ... - D_POSIX_PTHREAD_SEMANTICS [
library... ]

int *readdir_r(DIR *dirp, struct dirent *entry, struct
dirent **result);

readdir_r() has the equivalent functionality as readdir()
except that a buffer result must be supplied by the caller
to store the result. The size should be sizeof(struct
dirent) + {NAME_MAX} (that is, pathconf(_PC_NAME_MAX)) + 1.
_PC_NAME_MAX is defined in <unistd.h>.

The POSIX readdir_r() function initializes the structure
referenced by entry and stores a pointer to this structure
in result.

Clemens

>
> - Chad
>