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: Greg Troxel
Subject: Re: [gpsd-dev] Lots of warnings
Date: Fri, 12 Aug 2016 14:57:41 -0400
User-agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.5 (berkeley-unix)

"Gary E. Miller" <address@hidden> writes:

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

POSIX clearly says that time_t must be an integer type.  So systems that
have float time_t are incorrect per POSIX.   Do you mean clock_t, which
can be float?  What system?

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html

(To find what posix says, I search for

  site:opengroup.org 2013 time.h

and then I followed the link to sys/types.h.)

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

POSIX is not wishful thinking; it is the dominant standard.  So code
should be first written relative to the standard, assuming only what the
standard guarantees.  Then, if there are systems that don't follow the
standard, workarounds can be added, as long as they don't break
conforming systems.  I am certainly not under the delusion that all
systems are 100% compliant.  But in reality most systems these days
(that are at all posixy) are very good about POSIX compliance.

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

Sorry, I steered you wrong.  The presence of that file is an
implementation detail on BSD, which has a machine-independent header
inttypes.h as required by POSIX:

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/inttypes.h.html

and some of the content is in various machine/foo.h headers that are
different for different CPU types.  I didn't realize that when grepping.

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

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.

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

If long long and %lld works on all systems anybody has, that seems like
an ok compromise.

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

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

------------------------------
#include <stdio.h>
#include <inttypes.h>

int
main(int argc, char **argv)
{
  int64_t foo;

  foo = 3;

  printf("foo is %" PRId64 "\n", foo);

  return 0;
}

Attachment: signature.asc
Description: PGP signature


reply via email to

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