Re: [gpsd-dev] featuretest macros

[Greg Troxel]

"Gary E. Miller" <address@hidden> writes:

> What is a "correct warning?

The ones I sent a few days ago were on netbsd-8.  By correct, I meant
that reading the source, I concur with the compiler that a warning is in
order.

>> Certainly, if one defines _XOPEN_SOURCE to 700 and does not define
>> _NETBSD_SOURCE, then there are lots of undeclared functions.  Which is
>> correct, as _XOPEN_SOURCE is a request to make visible the symbols
>> specified by that standard, and no more.
>
> Uh, which is it now?  You need _NETBSD_SOURCE, or not?

I do not need it, unless I also have XOPEN_SOURCE, in which case I do.
Because the default behavior is to implicitly define _NETBSD_SOURCE
unless some other visibility defines are present.

> And we can't remove _XOPEN_SOURCE, and others, from gpsd as Python.h
> defines it.  Not much t gpsd without Python.h

That is arguably a bug in python.  Defining _XOPEN_SOURCE means that it
is correct that any functions not defined in that version of python are
hidden.  So if python does that, any program that does that should limit
itself to that version of XOPEN.   And if we don't like that, we should
be clear that we are fighting python's view of the world.

>> My point is that _XOPEN_SOURCE and _NETBSD_SOURCE is exactly
>> equivalent to not defining anything.  Unless there is some bizarre
>> function required by some version of XOPEN that is hidden by default,
>> but that does not seem to be the case.
>
> Not what Fred found on older NetBSD.  You keep limiting the problem
> horizon to way too small a range.
>
> Let us stop guessing, and wait until we can test again.

Fair enough.

>> To me, the biggest improvement would be to limit the defines intended
>> for glibc to systems with glibc.  That allows separate systems to be
>> worked on separately.
>
> 100% agreed.  The problem is that XOPEN_SOURCE and _NETBSD_SOURCE
> are used by much moe the globc and NetBSD.
>
> Can we just sheve this until after 3.19?  I'm not getting any
> work one on the dylib problem while stamping out mis-statements
> about these defines.

Ok.  I'm done until 3.19 on this - a perfectly reasonable request on
your part.