gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] Lots of warnings


From: Gary E. Miller
Subject: Re: [gpsd-dev] Lots of warnings
Date: Fri, 12 Aug 2016 12:16:26 -0700

Yo Greg!

On Fri, 12 Aug 2016 14:57:41 -0400
Greg Troxel <address@hidden> wrote:

> > Actually, on some systems time_t is a float.  What spec says that?  
> 
> POSIX clearly says that time_t must be an integer type.

gpsd runs on non-POSIX systems.  gpsd hopes for POSIX-2001, but does not
insist on it.

Plain C99 does not specifiy that time_t is an integer.

> > Even GNU date does not get it right, so we need to reflect reality,
> > not wishful thinking.  
> 
> date (on systems with int32_t time_t) fails to work in 2038, but I
> think it still conforms to POSIX.

Yes.  It is possible to be compliant and broken.

> > 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 had thought this was in C99.  Looking at the actual ISO C99 standard
> (which I can't share, but you can probably find a draft), section 7.8
> on page 197 says that "hosted implementations" must provide PRIdN
> etc.  I think gpsd is only targetted to hosted implementations, since
> it assumes file IO, select, networking, etc. already.

Good enough for me.  gpsd insists on C99 and you say C99 must have it.

> Assuming for a moment that I am confused (ISO specs are hard to read)
> and that PRId64 is a POSIX extension, that's mostly fair enough.  I
> guess gpsd should depend on C99 only, plus insist that any features
> that it uses from POSIX comply with POSIX.  Certainly things like
> select are not in C99 though, so there is already some significant
> amount of POSIX required.

select() is in POSIX-2001 and gpsd prefers that.

> > I'll play with it, but until we can insist on POSIX 2008 I'm
> > reluctant.  
> 
> If long long and %lld works on all systems anybody has, that seems
> like an ok compromise.

And if time_t is a float the truncation is a good thing.

> > For example, it is not present in macports, which I use to compile
> > gpsd on OS X.  
> 
> That's bizarre.  I just wrote the following, and built it, using
> command-line tools on OS X 10.9.  It also builds on NetBSD 7 with gcc
> 4.8 and NetBSD 5 with gcc 4.1.3.  I bet it's ok on all or your systems
> too.

I said 'not present', ad opposed to 'not working'.  MacPorts pulls in
a lot of stuff from OS X by way of Xcode.

My Xcode/MacPorts is broken right now.  So good to know it works.  Maybe
it is pulling it from the 'gcc' internals includes.

I still annows my they use 'gcc' for something not gcc.

> With macports, what is the compiler and where are the headers coming
> from?  Mac has had this sort of thing for a long time.

Latest Xcode, but until I get it working we know the problem is on my end.

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

Attachment: pgpyCSE66HlpH.pgp
Description: OpenPGP digital signature


reply via email to

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