|
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:1.9.2.9) 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> ... 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
[Prev in Thread] | Current Thread | [Next in Thread] |