Re: [patch] libstdc++/67747 Allocate space for dirent::d_name

[Martin Sebor <msebor at gmail dot com>]

On 10/02/2015 11:09 AM, Florian Weimer wrote:
> On 10/02/2015 06:57 PM, Martin Sebor wrote:
>
> > Readdir isn't required to be thread-safe (it may reference global
> > data) so calling it in multiple threads even with a different dirp
> > argument is undefined. A thread-unsafe implementation can meet the
> > POSIX requirement and still access global data but without locking.
>
> A readdir implementation which is not thread-safe when used with
> different directory streams is just buggy.  It may be conforming, but so
> is an implementation that always fails with EOVERFLOW.

POSIX is clear: The readdir() function need not be thread-safe.
There's nothing wrong with relying on a function's thread safety
when it's documented to be thread safe by the implementation,
even if POSIX doesn't guarantee it. But doing so otherwise,
against both the standard and against the documentation, would
be risky to say the least.

> > The Solaris implementation, for example, is explicitly documented
> > as thread unsafe.
>
> MT-safety is ambiguous for functions which operate on pointer arguments.
>   It is not clear if it is permitted to call the function without
> synchronization on overlapping objects.
>
> memcpy has the same thread-safety level as readdir on Solaris

I'm not sure what you are basing this assertion on. In the man
pages I have looked at, memcpy is documented as MT-Safe. readdir
is documented as MT-Unsafe. The Unsafe definition is clear:
contains global and static data that is not protected.

For example, Solaris 11.2:
http://docs.oracle.com/cd/E36784_01/html/E36874/readdir-3c.html
http://docs.oracle.com/cd/E36784_01/html/E36874/memcpy-3c.html

Martin