Re: Invalid position given by Telit HE910-EUG

[Greg Troxel]

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

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.  You don't really need to know if you are cross, if you only do
things that are cross safe.

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

Perhaps it takes a printf format specified to throw a (fatal) warning,
like:

{
        time_t t = 1;
        printf("%" PRI64 "d", t);
}


Then the build will know, if that builds, that time_t is big enough for
the next 100 years, and if that doesn't build, that it isn't.   I think
it's ok if for now this only works for systems where time_t is int32_t
or int64_t, until we know of an actual system that is something else.
(I think POSIX actually allows double, but that's nuts, and int128_t is
valid but silly.)