Add realpath Prototype
Craig Howland
howland@LGSInnovations.com
Wed Nov 20 16:14:00 GMT 2013
On 11/20/2013 10:02 AM, Corinna Vinschen wrote:
> On Nov 20 08:35, Joel Sherrill wrote:
>> On 11/20/2013 8:26 AM, Corinna Vinschen wrote:
>>> On Nov 20 07:38, Joel Sherrill wrote:
>>>> On 11/20/2013 3:46 AM, Corinna Vinschen wrote:
>>>>> On Nov 19 12:42, Corinna Vinschen wrote:
>>>>>> On Nov 18 13:32, Joel Sherrill wrote:
>>>>>>> On 11/18/2013 12:33 PM, Yaakov (Cygwin/X) wrote:
>>>> . Thanks. The guards are tricky. glibc has
>>>>
>>>> #if defined __USE_BSD || defined __USE_XOPEN_EXTENDED
>>>>
>>>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/realpath.html
>>>>
>>>>
>> marks it as XSI with no explicit macros that I am spotting.
>>>> Is that close enough?
>>> I don't understand the question. BSD and XOPEN don't correspond
>>> to strict ANSI.
>> I was just pointing out that glibc has BSD and XOPEN as guards.
>> Is that equivalent?
> It's not exactly equivalent, but __USE_BSD and __USE_XOPEN_EXTENDED
> are probably not set if strict ANSI is requested.
>
>
> Corinna
I propose that we use only #if !defined(__STRICT_ANSI__). We could spend many,
many hours trying to add "proper" gates to many functions, but there is very
little gain to be had by such an effort. Determining what is "correct" across
all flavors and stuff would be very difficult, if not impossible.
For example, we could rather easily use the __POSIX_VISIBLE that Sebastion
points out is in use by Free BSD, for example--a good thought. But this is not
fully correct, even for POSIX, because it is an over-simplification. realpath
is listed as having been added for POSIX version 2, so that it really should not
be included for POSIX 1. But, as already discussed and accepted for readdir_r,
that version change was more than 20 years ago, and the distinction does not
really make sense now--using __POSIX_VISIBLE would not be an unreasonable,
although not-completely-accurate, gate.
However, the thing of primary interest here, I think, is that realpath is in
stdlib.h, which is an ANSI C header. So if someone wants strict ANSI, leave it
out. Otherwise, let it be there and spare the pain of figuring out whether
POSIX or BSD or whatever has it. (That is, why even bother with POSIX_VISIBLE?
It's only the prototype. It's not like we're leaving it out of the library.)
Newlib is not trying for strict POSIX compliance, is it? (Loose, perhaps, but
not strict.)
I suggest that this be the principle to be used up to some cutoff date. So, for
example, something added in POSIX 2008 perhaps should have a version gate.
(This would be a much more tractable problem.) Or do we even want to bother
with that? Perhaps a new thread should be started to try and decide a general
policy so that we don't need to try and answer the question for every function
that might need some help. Do you have more in your list to be done, Joel, or
is this close to the last of this flavor?
Craig
More information about the Newlib
mailing list