Re: ✘gpsd .23.2~rc1

[Gary E. Miller]

Yo Fred!

On Mon, 11 Apr 2022 16:29:51 -0700 (PDT)
Fred Wright <fw@fwright.net> wrote:

> On Sat, 9 Apr 2022, Gary E. Miller wrote:
> > On Sat, 9 Apr 2022 13:26:00 -0700 (PDT) Fred Wright
> > <fw@fwright.net> wrote:  
> 
> >>>> That's a long-standing problem related to the way Qt support
> >>>> works. The warning only shows up with certain versions of clang,
> >>>> and in spite of the deprecation warning, I've yet to see a
> >>>> version that refuses to compile it.  
> >>>
> >>> I suspect you are correct, but without the build log, we are jsut
> >>> guessing.  
> >>
> >> I'm not guessing at all.  I explained it in the paragraph you
> >> snipped. It's fully understood and has been around for years.  
> >
> > Then I obviously failed to comprehend.  But rather than explain it
> > to someone that does not care, maybe just go fix it?  
> 
> Because:
> 
> 1) It takes quite a bit of work to fix.
> 
> 2) There isn't currently a good test to ensure that the fix doesn't
> break it.
> 
> 3) Aside from the kludgy code organization, the only issue is some 
> ignorable warnings from some compilers.
> 
> 4) It's been around for years, probably since the Qt support was
> first added.
> 
> As I said, on my list but not a high priority.

So we basically agree.

> >>>> AFAIK, the rouge gems are not a general requirement for
> >>>> asciidoctor. When I looked into this a bit, I found something
> >>>> that indicated that this error is often caused by something being
> >>>> specfied incorrectly so that it falls back to needing 'rouge',
> >>>> but that's as far as I got. I'm not aware of any actual problem
> >>>> caused by the absence of 'rouge', so I didn't bother digging
> >>>> further.  
> >>>
> >>> What is "rouge"?  gpsd does not use it, so not a gpsd problem.  
> >>
> >> It's what the complaint is about.  
> >
> > Now we are just getting circular.  I am totally lost.  
> 
> The original complaint was about the warnings from asciidoctor about 
> missing rouge gems.  Some information indicates that this is due to 
> something wrong in the asciidoctor input, but it hasn't been a high 
> priority to track down.

I have no such information.  If I missed something, please point
it out.  The Asciidoctor stuff builds with zero warnings for me.


> >>> Rounding error:
> >>>
> >>> - "altHAE":26.1200,
> >>> + "altHAE":26.1199,
> >>>
> >>> printf() is supposed to round for us.  So another glitch in your
> >>> libc.  
> >>
> >> It's not a rounding issue.
> >>
> >> Suppose one platform computes 26.1199500000 and another computes
> >> 26.1199499999.  The difference is infinitesimal, but they still
> >> round differently.  In general, floating-point comparisons should
> >> use fuzz. *Most of the time*, the discrepancy lands in a single
> >> rounding bucket, so it's covered up by rounding, but occasionally
> >> it straddles a rounding boundary and shows up in the output.
> >> Rounding is not a *guaranteed* substitute for fuzz.  
> >
> > In IEEE754, it is guaranteed.  Modern C compilers are supposed to
> > follow IEEE 754.  
> 
> That's not relevant.  Consider:
> 
> One compilation of the code performs all operations using double 
> precision, meaning that every intermediate result is rounded to
> double precision, usually introducing a certain amount of error which
> accumulates through the operations.  The other compilation uses
> extended precision for all intermediate results, with only the final
> result being rounded to double precision.  The latter is more
> accurate due to less cumulative roundoff error, but less reproducible
                       ^^^^^^^^^^^^^^^^^^^^^^^^^

> since not all platforms support extended precision.  Because of the
> difference in internal roundoff errors, the two versions may produce
> slightly different results from the same input.

A long way around, but you finally used the same words I did:
    roundoff error

So we agree.

> The discrepancy arises because some compilers, under some
> circumstances, decide to be "helpful" by treating some intermdeiate
> values as extended precision even when everything is specified as
> "double".

Which violtes IEEE754, and thus the C standard.  Since gpsd requires
C standard compliance, and thus IEEE754 compliance, they are broken.

> > OTOH, if you see a fix, please give it a try.  
> 
> Working on it.  It requires comparative debugging between two
> platforms, to track down where they diverge.  There's probably some
> way to disable the "unsolicited long double" behavior globally, but
> that would be a more impactful and riskier change to do right before
> a release.

Actaully, a global to enforce C compliance would be my preferred
solution.

> >>> Does macOS document any POSIX incompatibilities in shmat(),
> >>> shmdt(), shmctl(), etc?  
> >>
> >> It's not an incompatibility to exhaust the configured file
> >> descriptor limit.  
> >
> > Yes, your point?  
> 
> The error relates to a shmat() failure due to running afoul of the fd 
> limit.

Uh, what fd limit?  gpsd does not use a lot of file descripors.  If
6 is too many then gpsd will never work.


> It has nothing to do with "POSIX incompatibilities".

Maybe yes, maybe no.  Past experience is that macOS is not very POSIX.
But we don't know until we know.

> It's 
> actually mostly harmless in this context since the regression tests
> don't use SHM at all,

We agree, which is why it did not get fixed until yesterday.

> but if one wants to get rid of the errors, the
> options are to increase the fd limit or to decrease the parallel
> process limit by specifying a smaller -j value to SCons.

Since I do not have macOs anymore, somone else will have to test.

But the regression tests are currently run one at a time, so -j is
not related to this issue.

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

pgp157KJLdjBM.pgp
Description: OpenPGP digital signature