gpsd-dev
[Top][All Lists]
Advanced

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

Re: Invalid position given by Telit HE910-EUG


From: Gary E. Miller
Subject: Re: Invalid position given by Telit HE910-EUG
Date: Sun, 5 Apr 2020 17:47:06 -0700

Yo Greg!

On Sun, 05 Apr 2020 19:19:23 -0400
Greg Troxel <address@hidden> wrote:

> "Gary E. Miller" <address@hidden> writes:
> 
> >> That build/run should obviously be conditional on not doing cross
> >> compliation, with the usage either skipped or somehow worked
> >> around if so.  
> >
> > It has to be run, somehow.  Ideas and/or patches welcome.  
> 
> Well, really you are saying, I think, that when gpsd runs, it needs to
> be able to know if time_t is more or less int32_t or int64_t.  That is
> not the same as needing to run a program at build time.

Yes.

> But, the real problem here is not doing a compile at build time, it is
> running a program built during the build, which you can't do in a
> cross world.

Yup.

>  You don't really need to know if you are cross, if you
> only do things that are cross safe.

Easily said.  Don't see how that is possible automagically.  The
only way I see around the time_t problem with cross-compiling is a
cross-compling flag.  That flag the requires a manually entered time_t
size.

> So a program could do something like
> ----------------------------------------
> #include <stdint.h>
> #include <time.h>
> main()
> {
>         int64_t t64 = 0x100000000;
>         time_t tmabybe = t64;
> }
> ----------------------------------------
> and be built with -Wall -Werror so that it gives a compile-time
> failure if time_t is int32_t (or some other type that amounts to the
> same thing).

Nice idea, but -Wall and -Werror are not universal compiler options.  This
needs to support all possible tool chains.

>  I can't test that because all my 32-bit systems are
> NetBSD which uses int64_t for time_t regardless of cpu type (for ~10
> years). Somebody with Linux i386, armv7, sparc, should be able to try
> it quick.

Not gonna be arch dependent, it will be C compiler dependent.

I would also like to see the results.


> Perhaps it takes a printf format specified to throw a (fatal) warning,
> like:
> 
> {
>         time_t t = 1;
>         printf("%" PRI64 "d", t);
> }

Only the newest C compilers check the printf() format string.  And very,
very, few compilers implement PRI64 properly.  gpsd tried it and had
to revert.

This needs to work on 15 year old compilers.  And clang.  No support
for -Wall or -Werror on clang.

And it is only one of many values that gpsd needs to discover.  Which is
why I think build time options are the way to start.  Then if people
can come up with magic solutions those can be added.

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

Attachment: pgpSyWLnj9zld.pgp
Description: OpenPGP digital signature


reply via email to

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