Re: [Xen-devel] [PATCH 1/2] libfsimage: replace deprecated readdir_r() with readdir()

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ian Jackson writes ("Re: [Xen-devel] [PATCH 1/2] libfsimage: replace deprecated 
readdir_r() with readdir()"):
> 2. There may be good reasons to deviate from a formal specification.
> Formal specifications can be wrong (for example, they can differ from
> established practice, or unuseable, or incoherent).  But there has
> been no discussion (at least in this thread on xen-devel) which might
> suggest that the POSIX specification is wrongheaded here.

I have been helpfully referred by a local irc channel to the following
attempt to change posix to require that readdir() is threadsafe in the
senses required by libx, and to deprecate readdir_r():

 http://austingroupbugs.net/view.php?id=696

I find the comment 0001606 by "dalias" (et seq) totally convincing.
The published specification of readdir_r is indeed incoherent.  And
only contrived implementations of readdir will not be threadsafe in
the required sense.

> 3. Perhaps the documentation accompanying, or discussion justifying,
> the glibc readdir deprecation warning, will provide something
> resembling what I discuss in (2).
> 
> 4. I am not satisfied with an approach which enumerates all the
> currently-supported dom0 operating systems.  These patches should be
> accompanied by an explantion of a good reason to believe that all
> operating systems we are likely to ever want to run on (or be able to
> run on) will also provide a threadsafe readdir.

I think the comments by dalias in the thread above, provide exactly
the justification I wanted in my paragraphs 2-4 above.

Accordingly, I think all occurrences of readdir_r in our codebase
should be replaced by readdir, as proposed by Chris.

However, I think the patch is not quite complete, as the change from
readdir_r to readdir should also involve removing the local dirent
variables associated with each call site.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel