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

[Fred Wright]

On Thu, 13 Jun 2019, Gary E. Miller wrote:
> On Wed, 12 Jun 2019 20:51:43 -0700 (PDT)
> Fred Wright <address@hidden> wrote:
>
> > On Wed, 12 Jun 2019, Gary E. Miller wrote:
> > > On Tue, 11 Jun 2019 23:20:23 -0700
> > > Hal Murray <address@hidden> wrote:
> > >
> > > > plus lots of
> > > > gpsd_json.c:150:11: warning: implicitly declaring library function
> > > > 'strlcpy' with type 'unsigned int (char *, const char *, unsigned
> > > > int)' [-Wimplicit-function-declaration] and friends
> > >
> > > I found the FreeBSD string.h here:
> > >
> > > https://github.com/freebsd/freebsd/blob/master/include/string.h
> > >
> > > That shows __BSD_VISIBLE needs to be defined.  Of course not in the
> > > man page.
> > >
> > > Can you try that before I make a bunch of changes to define that?
> >
> > 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.

> 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:

-#ifdef __linux__
-/* FreeBSD chokes on this */
-/* getsid() needs _XOPEN_SOURCE, 500 means X/Open 1995 */
-#define _XOPEN_SOURCE 500
-#endif /* __linux__ */
-
-#if !defined(_POSIX_C_SOURCE) || _POSIX_C_SOURCE < 200112L
-/* isfinite() and pselect() needs  _POSIX_C_SOURCE >= 200112L */
-#define  _POSIX_C_SOURCE 200112L
-#endif
+/* getsid() needs _XOPEN_SOURCE */
+/* 500 seems to be sufficient for Linux, but some BSDs need 700 */
+#define _XOPEN_SOURCE 700

-/* strlcpy() needs _DARWIN_C_SOURCE */
+/* strlcpy() and strlcat() may need one of these, depending on platform 
*/
+#ifndef __linux__  /* Avoid deprecation warnings on some Linuces */
 #define _DARWIN_C_SOURCE
+#define _BSD_SOURCE
+#define _NETBSD_SOURCE
+#endif /* !__linux__ */

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.

> It does look like _POSIX_C_SOURCE can be used to set __DARWIN_C_LEVEL,
> so maybe *BSD is similar?
>
> 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.

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.

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'd already spent considerable time investigating this (leveraging
> > the fact that I have three BSDs, three Linuces, and 9 OSXes to test
> > against), but it looks like it's become too much of a moving target
> > to continue.
>
> The target is not moving, but the gpsd code is.  With Hal's help I think
> we almost have this fixed.  These defines have been a mess, I'm trying
> to move all the various and slightly different versions into one version
> in SConstruct.  Almost there.
>
> 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, 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.

> 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.

Fred Wright