Re: [PATCH] readdir, readdir64 are thread-safe

[Florian Weimer <fweimer at redhat dot com>]

On 04/11/2017 03:16 PM, Zack Weinberg wrote:
> On Tue, Apr 11, 2017 at 7:36 AM, Florian Weimer <fweimer@redhat.com> wrote:
> > They only modify the state in the dirstream argument, and we
> > generally do not treat this as a reason to mark a function as
> > not thread-safe.  For an example, see random_r, which is marked
> > as thread-safe even though the random state is not protected
> > by a lock.
>
> Hmm.  There's two issues here: first, POSIX specifically allows
> readdir to be not thread-safe (although it's unclear to me what that
> actually means) so it might be appropriate to keep the annotation
> around to warn people that there is a portability concern;

The cost of that is that people use readdir_r instead, which is not what 
we want at all.

> second, if
> you share a DIR object among threads, a call to readdir in one thread
> will clobber the previous return value, which might still be live in
> another thread.

That's true for file positions and FILE * objects, too.

> Is that sufficient reason to call the *function*
> thread-unsafe?  We don't have any good place to warn people about that
> *other* than the documentation for readdir.  (Note that the text of
> the @deftypefun does a very bad job of explaining what the problem
> is.)

I don't understand your comment about @deftypefun.

The problem here is that people avoid readdir and jump through the hoops 
required to use readdir_r, either introducing security vulnerabilities 
or interoperability issues in the process.  (It's all related to the 
missing buffer size argument, similar to realpath's second argument.)

As usual,  people assume that because libcs and POSIX define readdir_r, 
it is a desirable interface to have, but that is wrong.

Thanks,
Florian