Re: [gpsd-dev] Lots of warnings

[Fred Wright]

On Wed, 10 Aug 2016, Joshua Judson Rosen wrote:

> On 08/09/2016 09:49 PM, Gary E. Miller wrote:
> >> timespec_str.c:48:12: warning: absolute value function 'labs' given
> >> an argument of type 'const time_t' (aka 'const long long') but has
> >> parameter of type 'long' which may cause truncation of value
> >> [-Wabsolute-value]
> >
> > Huh???  time_t is a long!
>
> 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).
>
> In order to have a 64-bit time_t and escape the 2038 problem,
> wouldn't time_t have to be at least equivalent to "long long"
> on 32-bit platforms where "long" is still only 32 bits?

Exactly.  Some OSes have been moving to 64-bit time_t in order to be
"2038-ready".  But it's not as simple as just changing the typedef, since
there are time_t fields in some structures whose binary layout is rendered
incompatible by the change.  OpenBSD decided to take the heavy-handed
approach and just make people fix anything that broke with a 64-bit
time_t.

There's a similar issue in moving to 64-bit inodes.  A nice side effect of
64-bit inodes is that they took advantage of the unavoidable breakage of
struct stat to add subsecond resolution to the timestamps, as well as
adding creation time in some cases.

OSX handled the switch fairly well, by making the inode size a compile
flag, initially defaulting to the backward-compatible 32 bits in 10.5, and
then defaulting to 64 bits in 10.6 and later.  Linux originally just tied
it to sizeof(long), but they seem to have relented more recently (on
ino_t, not time_t).

It's too bad that time_t wasn't changed at the same time, since struct
stat will need to change *again* when going to 64-bit time_t.

> I for example haven't had any desktops there were less than 64-bit for a 
> while,
> but I still have *lots* of 32-bit embedded Linux devices--ranging
> from cheap routers to expensive robots.

Indeed.  As long as the OS folks accept the idea that 32-bit processors
may still be in use in 2038...

Fred Wright