<<< Date Index >>>     <<< Thread Index >>>

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



>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