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

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

On 06 Nov 05, at 01:00, Casper.Dik@xxxxxxx wrote:
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.
In practice, you're correct. In theory, however, consider the following code 
path.



THREAD 1                          THREAD 2
------------------------------    ------------------------------
DIR *d1 = opendir(dir1);
                                  DIR *d2 = opendir(dir2);
dent1 = readdir(dir1);
                                  dent2 = readdir(dir2);
use(dent1);
In most implementations, dent1 != dent2. HOWEVER, there is no guarantee that they will not both point to the same statically allocated buffer, and some implementations may do so. For example, this is why ctime_r exists: ctime returns a pointer to a statically allocated buffer, and hence is not thread 
safe.

You are correct, though, that the glibc implementation of readdir is
thread-safe, so readdir_r is unnecessary in all common situations.

Attachment: PGP.sig
Description: This is a digitally signed message part