Re: [gpsd-dev] Today's warnings.... / Lots of warnings

[Fred Wright]

On Fri, 12 Aug 2016, Gary E. Miller wrote:
> On Fri, 12 Aug 2016 03:53:38 -0700
> Hal Murray <address@hidden> wrote:
>
> > From Fedora 24,
> >   cc (GCC) 6.1.1 20160621 (Red Hat 6.1.1-3)
> > bits.c:40:19: warning: left shift of negative value [-Wshift-negative-value]
> > bits.c:71:15: warning: left shift of negative value [-Wshift-negative-value]
> > bits.c:40:19: warning: left shift of negative value [-Wshift-negative-value]
> > bits.c:71:15: warning: left shift of negative value [-Wshift-negative-value]
>
> Eric had thoughts on that one, I'll leave it to him.

I personally consider that one to be overly pedantic.  It's based on the
fact that the C standard considers that case to be undefined, but I don't
see any reason for the latter other than to allow for non-twos-complement
processors.  I would be very surprised if any twos-complement processor
gave different results for X << Y than for X * (1 << Y), at least in
non-overflowing cases.  Assuming GPSD isn't trying to be compatible with
non-twos-complement processors, it might make sense to disable that
warning when it exists.

On Fri, 12 Aug 2016, Greg Troxel wrote:
> "Gary E. Miller" <address@hidden> writes:
>
> > 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.

And even so, if it fails on 64-bit times then it's because of *its own*
Y2038 bug, which *also* needs to be fixed.  If everyone adopted the
philosophy of not fixing their Y2038 bugs until everyone else had fixed
*their* Y2038 bugs, then that would constitute what hardware designers
refer to as a latch. :-)

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

Given that any C99 system should have "long long", that's a less demanding
approach.  For actual 64-bit values, casting [u]int64_t to [unsigned] long
long is a NOP anyway.  For 32-bit values, gratuitous 64-bit promotion does
add overhead, but most uses of printf() and friends aren't expected to be
really fast, anyway.  If there were a time-critical case, a bitness
conditional would be justifiable.

It should be noted that stdint.h typically won't compile with a pre-C99
compiler (at least 32-bit targets), due to the use of "long long".  So
anything using the stdint types can reasonably assume the availability of
"long long".

On Fri, 12 Aug 2016, Hal Murray wrote:
> address@hidden said:
> > 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?
>
> python uses double for time.time(), but that's neither POSIX nor time_t.

Indeed.  Actually, my recollection is that time.time() was originally an
int, and later changed to be a float (Python float, i.e., double), but I
haven't had any luck digging up that bit of history.

> I haven't counted the bits to see when it starts dropping microseconds.  It's
> clearly no good if you expect nanosecond accuracy.

The IEEE-754 64-bit format has a 52-bit mantissa (not including the sign),
which loses microsecond precision after about 142.7 years.

It only takes 52 days to lose nanosecond precision.

Some things that aren't constrained by compatibility have adopted 64-bit
nanoseconds as a time representation.  Even as a signed quantity, that's
good for 292 years.

Fred Wright