Re: [gpsd-dev] Lots of warnings

[Gary E. Miller]

Yo Greg!

On Thu, 11 Aug 2016 20:30:34 -0400
Greg Troxel <address@hidden> wrote:

> "Gary E. Miller" <address@hidden> writes:
> 
> >> Not according to that error-message, which says that it's a *long
> >> long* (like in the opening line of the song "American Pie", not in
> >> the opening line of the Star Wars Episode IV).  
> >
> > Well, I can not duplicate that error message on any 32 bit system I
> > have.  
> 
> This kind of thing needs to be done by reading specs, not trying
> particular systems.  There are no guarantees on time_t other than that
> it is a reasonable integer type.

Actually, on some systems time_t is a float.  What spec says that?

Even GNU date does not get it right, so we need to reflect reality, not
wishful thinking.

> > So 32 bit Pi is broken past 2038.  
> 
> On Linux/Pi; this is not about the hardware.

Yeah, I should have mentioned Gnu/Linux Pi.

> time_t is int64_t on NetBSD/Pi.

my 'long long' patch covers that.

> On NetBSD, time_t used to be long, like it was everywhere else, and
> in 6 was changed to int64_t.  So regardless of CPU type, it's big
> enough. I'm surprised this hasn't happened on the Linux/Pi system;
> 2038 is starting to seem conceivable, now that 2000 is a distant
> memory.

Yeah, I was also surprised.  Sadly the Pi forks of most distros are
really out of daet and unpatched.

> > In any case, I just changed my patch to use long long.  Now
> > timespec_str() is good to: Sat Nov 20 09:46:39 PST 2286
> >
> > I sure wish printf() understood uint64_t.  
> 
> It does; PRIu64.  See int_fmtio.h, which I think implements format
> specifiers from 7.8.1 of C99.

I do not have that file anywhere.  Not in /usr/include or in the
glibc source.

I do find /usr/include/inttypes.h has what you are talking about.

> http://stackoverflow.com/questions/16859500/mmh-who-are-you-priu64

Interesting.

> If gpsd doesn't require C99, things are much harder.

gpsd does, but only the parts that actually work most places.

I notice that inttype.h calls it self an extention of C99.  Specifically
POSIX.1‐2008.  I'm not ready to enforce that in gpsd.

> I would recommend casting to int64_t and using PRId64.

I'll play with it, but until we can insist on POSIX 2008 I'm reluctant.

For example, it is not present in macports, which I use to compile gpsd
on OS X.

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

pgpAWplzosvim.pgp
Description: OpenPGP digital signature