Re: [Full-disclosure] Re: readdir_r considered harmful

[Casper.Dik () Sun COM]

> Then you never really understood the implementation, seems.  Of course
> all implementations keep the content of the directory as read with
> getdents or so in the DIR descriptor.  But it is usually not the case
> that the whole content fits into the buffer allocated.  One could, of
> course, resize the buffer to fit the content of the directory read,
> even if this means reserving hundreds or thousands of kBs.  But this
> is not how most implementations work.

I don't see how that is relevant; the typical use of readdir() is as follows:

        DIR *dirp = opendir(name);

        while ((dent = readdir(dirp)) != NULL) {
                ...
        }

        closedir(dirp);

Nothing other threads do with readdir() on different dirp's will influence
what "dent" points to.

I have *never* seen a program where multiple threads read from a single
dirp; and I can't image the use.

> Instead implementations keep work similar to every buffered file I/O
> operation.  But this means that buffer content is replaced.  If this
> happens and some thread uses readdir() instead of readdir_r(), the
> returned string pointer suddenly becomes invalid since it points to
> memory which has been replaced.

Yes, the next call to readdir() *on the same dirp* may change what
the previous call; but that's completely irrelevant for most uses
of readdir().

Of course, an application may want to save all readdir() return values,
but that is completely orthogonal to threads; there is no reason
why the POSIX *thread* specification includes readdir_r().

> Next time, before you make such comments, ask Don Cragun to explain
> things to you.

Next time before you mail, you might want to engage your brain.

There is NO reason for a thread-safe library to use readdir_r() over
readdir(), with common readdir() implementations.

Casper