Re: ✘gpsd .23.2~rc1

[Gary E. Miller]

Yo Greg!

On Wed, 13 Apr 2022 07:49:53 -0400
Greg Troxel <gdt@lexort.com> wrote:

> I really don't see that this discussion is going in a useful
> direction.

I always prefer running code.

> I see the point about standards compliance.  But for better or for
> worse, C programs on x86 often have extra intermediate precision.
> Most of the world thinks that this is not really a bug.

I'd be happy to ignore the non-compliant cc's, and ship 3.23.2.

Other's disagree.

Fred thinks he can fix this.  Worth giving him that shot.

OVer a third of the regressions pass already, so the problem is small.

> It definitely seems suboptimal to end up with slower code for the sake
> of pedantry or accomodating tests.

I doubt it is measureable.  packet.c is where all the time goes in gpsd.

> A question would be if gpsd is getting arguably wrong results (wrong
> in a real sense, not a standards nitpicking exact sense) from this,
> or if it is just a test issue.

100% a test issue.  Tyring to compare strings.

> It would seem effort is better spent
> to enable tests to be considered passing, when computed with slightly
> more precision than the standard says, in the way that 99% of
> computers typically do.

How do you "compute" ascii?  Or do you want to rewrite the regression
test system with several more layers of abstraction?

> Writing a floating point conformance test suite is also a reasonable
> thing to do, but I think that's separate from gpsd.

See: tests/test_float.c.  And the recently added FLT_EVAL_METHOD checks.

I you can think of a test to add, please share.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgpUmZXEDvbtv.pgp
Description: OpenPGP digital signature