[Date Prev][Date Next][Thread Prev][Thread Next][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