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

[Gary E. Miller]

Yo Fred!

On Thu, 13 Jun 2019 13:29:52 -0700 (PDT)
Fred Wright <address@hidden> wrote:

> >> It's not in the man page because it's controlled by *other*
> >> includes, based on *other* config flags.  The general rule is that
> >> all double-underscore-prefixed flags are for the includes'
> >> internal use and should not be directly set by user code.  
> >
> > So do I need to be telepathic?  Or what?  
> 
> The "rule" is written down somewhere, though I don't remember exactly 
> where.

Yeah, no one seems to recall where.  I just looked at Python.h.  They
use the same double underscore we do.  When they figure it out, we'll
copy.
> 
> > If anyone has the incantation to set __BSD_VISIBLE, _BSD_SOURCE, or
> > __DARWIN_C_LEVEL a better way, then please speak up.  
> 
> Before the latest flurry of changes, I'd gotten libgpsd_core.c fixed
> with this:

Looks ptretty similar to what I just did.  Except mine get into
gpsd_confg.h, instead of being all over the place inconsistently.

> -#ifdef __linux__
> -/* FreeBSD chokes on this */
> -/* getsid() needs _XOPEN_SOURCE, 500 means X/Open 1995 */
> -#define _XOPEN_SOURCE 500
> -#endif /* __linux__ */

Notice the mess here?  Fixing FreeBSD by testing for not linux?

This is what I am fixing.  A FreeBSD patch should only affect FreeBSD.

> +/* getsid() needs _XOPEN_SOURCE */
> +/* 500 seems to be sufficient for Linux, but some BSDs need 700 */
> +#define _XOPEN_SOURCE 700

The code variously uses _XOPEN_SOURCE 500, 600 and 700!

By pulling into gpsd_config.h there is only ever one value for _ZOPEN_SOURCE.

> +#ifndef __linux__  /* Avoid deprecation warnings on some Linuces */
>   #define _DARWIN_C_SOURCE
> +#define _BSD_SOURCE
> +#define _NETBSD_SOURCE
> +#endif /* !__linux__ */

Fixing for osX by again testing for not linux?  Ugh.  Gone.

These are now added only for the proper OS.  I hope:

> +#define _BSD_SOURCE
> +#define _NETBSD_SOURCE

> I'd expected something like this to work on the other files as well,
> with the possible exception of the isascii case.  Since isascii is
> just a trivial one-line macro, it may make more sense to provide a
> local definition than to wrestle with the right feature-test
> incantation to get the one-line definition from the OS includes.

Ugh.  Duplicating 30 year old standard code has got to go.  Modern
compilers inline isascii().  We can't duplicate the efficiency.

> > Once we get all the warnings fixed with the magic defines, I'll
> > circle back to try to avoid the double underscore.  
> 
> The "no risky changes right before the release" intent would have
> been better served with a few focused tweaks, rather than opening
> Pandora's box.  Even so much as looking cross-eyed at any of those
> feature-test macros is dangerous without extensive multi-platform
> testing.

Well, seems to me I did take the least ricky approach.  Nothing is
really changing, just moved around, refactored, to be more consisten.

If the osX, FreeBSD and NETBSD users did not wait until the last moment
to test this could have been avoided.

> Although arranging a consistent setting of the feature tests across 
> modules is probably sensible in the long run, it's way too impactful
> for a last-minute fix, as the results have shown.

Thus, this is now no longer the last minute, but instead the last half-hour.

> Another possibility would be to move a few more things into the
> os_compat module, which was intended to be the place for all the
> messy OS_specific stuff, so that the rest of the code wouldn't need
> any of that crud.  But again, this isn't something I'd do right
> before a release.

I looked at that.  I could not make it work.

> > Right now osX, Linux and FreeBSD are good.  NetBSD has a few more
> > nits to fix.  
> 
> Actually, no.  Although things have improved a bit since last night,

Care to share?  Your results are not the same as from others.

Once again. my mind reading skills fail me.

> what I'm seeing now is way more warnings than a few days ago on every
> platform, and flat-out build failures on CentOS and OpenBSD.

Care to share?  Right now the fixes are rifle shot for one of:
        osX
        FreeBSD
        NetBSD

If you can tell me the platform string that scons sees for OpenBSD then
I can applu the FreeBSD defines to it as well.

What is CentOS like?  Does it also need __BSD_SOURCE, __BSD_VISIBLE, 
or?  What is the CentOS platform string?

> > Please consider testing when Hal and I think we are good.  
> 
> I can do that if it's soon.  But I have a trip out of the country
> coming up, and between the trip and the pre- and post-trip overhead,
> I'll be mostly unavailable for the last half of this month.

We take what we can get.  Your life comes first.

I'd like to solve this by Friday.

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

pgpSDsgEdkEXk.pgp
Description: OpenPGP digital signature