|
From: | Paul Eggert |
Subject: | Re: [PATCH] renameat: port to Solaris 10, which declares renameat in unistd.h |
Date: | Tue, 26 Oct 2010 15:14:02 -0700 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.14) Gecko/20101006 Thunderbird/3.0.9 |
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. 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).
[Prev in Thread] | Current Thread | [Next in Thread] |