gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] Warnings from 32 bit FreeBSD


From: Gary E. Miller
Subject: Re: [gpsd-dev] Warnings from 32 bit FreeBSD
Date: Tue, 18 Jun 2019 13:19:59 -0700

Yo Greg!

On Tue, 18 Jun 2019 15:52:13 -0400
Greg Troxel <address@hidden> wrote:

> I wonder how much of this feature test macro stuff can be avoided by
> just *not defining* _XOPEN_SOURCE in the first place.

If you look at git head, you will see _XOPEN_SOURCE is now only
defined one place.

In most OS I've looked at _XOPEN_SOURCE is redefined in either
<features.h> or <sys/cdefs.h>.  But a few older ones still need it.
I think.

So I suspect it usually does nothing at all now.

Please test.

> Generally, my impression is that most systems make available all of
> their definitions if no feature macros are defined.  And if some are,
> such as one that specifies a standard, then definitionss not specified
> in that standard are hidden.  This is useful when writing strictly to
> a standard, so that non-standard calls can be removed.

Sadly that is not the case on a few distros.  Please test and report.

For example.  On Linux.  
       isnan():
           _ISOC99_SOURCE || _POSIX_C_SOURCE >= 200112L
               || _XOPEN_SOURCE
               || /* Since glibc 2.19: */ _DEFAULT_SOURCE
               || /* Glibc versions <= 2.19: */ _BSD_SOURCE ||
               _SVID_SOURCE


> It may be that some systems (this seems more solarisy, from my very
> hazy memory), hide things that we expect unless something like
> _XOPEN_SOURCE is defined.

Yeah, but not always.  Found that out the hard way with Fred's
testing.

> Overall, your approach  to centralize this and to define
> _NETBSD_SOURCE and other similar things, per system, to get back the
> normal visibility sounds reasonable.

And I'd like to continue that way.  If you have an OS that does not
need _XOPEN_SOURCE, then I'd love to omit it from config.h.

A lot of progress so far, more to go.  But unless someone else tests
then I'm happy with it for this release.  Right now: "Ain't broke,
don't fix it"

Now I'm trying to figure out how to fix osX dylib's.  That is two of
the last 3 open issues.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

Attachment: pgpZG5J3adyYu.pgp
Description: OpenPGP digital signature


reply via email to

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