gpsd-dev
[Top][All Lists]
Advanced

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

Re: ✘gpsd .23.2~rc1


From: Fred Wright
Subject: Re: ✘gpsd .23.2~rc1
Date: Fri, 15 Apr 2022 13:52:17 -0700 (PDT)


On Thu, 14 Apr 2022, Gary E. Miller wrote:
On Thu, 14 Apr 2022 20:26:06 -0700 (PDT) Fred Wright <fw@fwright.net> wrote:

It's all very nitpicking except for the
tests, since it's about rounding a value that's nominally exactly
halfway between two allowable values in the JSON precision, which is
less than the uBlox precision.

Yeah, one decimal digit is lost in the JSON.  When I see a mm precise
GNSS, that will have to change.

Sure, hence the "nitpicking". But the wobbly results arise from the "lost" digit.

The whole JSON precision issue needs looking into, but not right now.

Been there, done that:

   https://gpsd.io/gpsd-numbers-matter.html

I think it would make sense to vary the JSON precison based on what the receiver provides. For further study.

For example, uBlox NAV-PVT reports altitudes with millimeter
precision, and NAV_HPPOSLLH provides 10-micron precision.  The JSON
has 100-micron precision, so it's overkill in the standard case and
deficient in the high-precision case.  Not that it's very likely to
matter in real use cases, since a receiver is hard pressed even to
deliver millimeter accuracy on a single real-time fix, especially in
the vertical dimension.

I think you mean hard pressed to deliver 0.01 meter accuracy.

I meant millimeter because that's what the receiver nominally provides even without "high precision".

Also, in spite of your attempts to control FLT_EVAL_METHOD, the
FLT_VOLATILE hack is still needed.  Taking it out caused about a
dozen errors on nmea-fuzzy-cases in 32-bit OpenBSD, so I put it back.

I tested it on FreeBSD, are they really different?

 It's a complete NOP any time FLT_EVAL_METHOD < 2, anyway.

No, valatile has real costs.

I didn't say "volatile" is a NOP; I said the change is a NOP in that case. Look at the code. The volatile is only present when FLT_EVAL_METHOD >= 2. Otherwise FLT_VOLATILE is empty.

My version now passes all tests on the 22 platforms I tested, which
wasn't true of yours.

Can you be more specific on the failing case?  I know that volatile is
not needed, but the full fix was not needed on my test case.

I could reconstruct that if necessary, but the point is that the volatile was very much needed on 32-bit OpenBSD. In my end result, only one value in a .chk file needed to be changed from everything before the recent changes, and I vetted that one. You can always diff the .chk files to see what changed.

And your #if broke one of Hal's old test cases.  Older cc do
not define FLT_EVAL_METHOD, your code requires it, thus an errorf.

Are you sure? I believe it was *your* use of FLT_EVAL_METHOD in runtime code that was the problem. Preprocessor numeric conditionals are supposed to regard undefined macros as having a value of 0, so my use of it is perfectly OK *in the preprocessor*. If for some reason it has to work with some really ancient compiler that doesn't follow that rule, then one could always apply the "+0 hack".

On Fri, 15 Apr 2022, Gary E. Miller wrote:

On Fri, 15 Apr 2022 02:12:00 -0700 Hal Murray <halmurray@sonic.net> wrote:

My setup uses clang on OpenBSD and FreeBSD.  Both provide a blizzard
of cc: warning: optimization flag '-fexcess-precision=standard' is
not supported [-Wignored-optimization-argument]

OpenBSD clang version 11.1.0
OpenBSD clang version 11.1.0 (32 bit)
FreeBSD clang version 11.0.1
FreeBSD clang version 10.0.0
FreeBSD clang version 11.0.1 (32 bit)

Yeah, for some reason the scons option checker misses that one.  I'll
play with it.

I believe the SCons option checker treats warnings as success, so it happily includes the gcc-only option for clang. Since gcc considers the clang-only option to be an error, and clang considers the gcc-only option to be a warning, the obvious fix is to try the clang option first and then only try the gcc option if the clang option is rejected, rather than just throwing them both into the general pile of optional options.

Fred Wright



reply via email to

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