Re: [PATCH] renameat: port to Solaris 10, which declares renameat in unistd.h

[Eric Blake]

On 10/26/2010 04:14 PM, Paul Eggert wrote:
> On 10/26/10 14:36, Eric Blake wrote:
> > Shouldn't the real fix to be fixing our<stdio.h>  replacement to pull in
> > <unistd.h>  prior to re-declaring renameat?  That is, our goal is that
> > all files except for .m4 probes and our replacement headers should be
> > immune to header reordering issues.
>
> Sure, but that goal is already met for code that uses gnulib.

No, it's not.  If I write a client package that uses the renameat 
module, and has a .c file with:

#include <config.h>
#include <stdio.h>
#include <unistd.h>
...
renameat();

then the replacement <stdio.h> MUST pollute the namespace (but for 
Solaris only, given Bruno's recent cleanups to avoid pollution on glibc 
systems) in order to avoid the client code running into the same problem 
as the gnulib lib/renameat.c.

> The problem happens only in the gnulib renameat implementation itself.
>
> Having<stdio.h>  pull in<unistd.h>  would pollute the name
> space of all of gnulib's client code.  It's not clear that this
> cost is outweighed by the relatively minor benefit of being
> able to reorder headers within one gnulib source file
> (lib/renameat.c).

We've done it for other functions, such as cygwin's symlinkat and 
unlinkat being declared outside of <unistd.h>, so there's already 
precedence for mandating the header namespace pollution on broken platforms.

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org