[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] renameat: port to Solaris 10, which declares renameat in uni

From: Eric Blake
Subject: Re: [PATCH] renameat: port to Solaris 10, which declares renameat in unistd.h
Date: Tue, 26 Oct 2010 17:16:33 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100921 Fedora/3.1.4-1.fc13 Mnenhy/0.8.3 Thunderbird/3.1.4

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>

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]