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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>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.

The standard actually guarantees that the static storage is
associated with the specific directory STREAM.  So a system on which
dent1 and dent2 point to the same buffer and reads from one stream
affect the buffer returned by reads from another stream are not
POSIX compliant.

See:

http://www.opengroup.org/onlinepubs/009695399/functions/readdir.html

    "The pointer returned by readdir() points to data which may be
    overwritten by another call to readdir() on the same directory
    stream. This data is not overwritten by another call to readdir()
    on a different directory stream."

But is also goes on to say:

    "The readdir() function need not be reentrant. A function that is
    not required to be reentrant is not required to be thread-safe."

which is the one thing I like POSIX to fix for thread safe implementations.

Casper

[Index of Archives]     [Linux Security]     [Netfilter]     [PHP]     [Yosemite News]     [Linux Kernel]

  Powered by Linux