On Wed, Apr 26, 2017 at 09:27:52PM +0100, Daniel Silverstone wrote:
On Wed, Apr 26, 2017 at 21:13:05 +0100, Richard Ipsum wrote:
> On Wed, Apr 26, 2017 at 08:51:42PM +0100, Daniel Silverstone wrote:
> > (a) older glibcs which have no statement regarding the safety of
> > readdir()
> In what way, other than thread safety, is readdir() unsafe on older glibcs?
Specifically thread safety.
> > and (b) many other platforms such as Solaris, and the *BSDs which
> > don't even use glibc.
> But these platforms also have readdir()?
Yes, but are those readdir() implementations threadsafe?
Right so I wasn't considering thread safety as an issue, but the following
is worth reading:
In the current POSIX.1 specification (POSIX.1-2008), readdir() is not
required to be thread-safe. However, in modern implementations
(including the glibc implementation), concurrent calls to readdir()
that specify different directory streams are thread-safe. In cases
where multiple threads must read from the same directory stream,
using readdir() with external synchronization is still preferable to
the use of the deprecated readdir_r(3) function. It is expected that
a future version of POSIX.1 will require that readdir() be thread-
safe when concurrently employed on different directory streams.
I couldn't find mention of thread safety in the FreeBSD man page for
readdir, and Solaris's man page says it's unsafe.
We can just #ifdef if that's what you'd prefer, I don't know how important
maintaining thread safety on BSDs and Solaris is to you.
One thing that just occurred to me is since it is possible on some platforms
that d_name may not be null-terminated when the length of the name exceeds
NAME_MAX, then the existing code might be broken anyway since lua_pushstring
expects a null terminated string and luxio doesn't check whether the string
is null terminated or not before passing it.
What do you think?