>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
