Re: ✘gpsd .23.2~rc1

[Fred Wright]

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.

> > > > 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.

> > > 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.

The final output is in decimal text strings, rounded to the nearest 
decimal representation in the specified number of digits.  Most of the 
time, the two slightly different results from the above land in the same 
decimal rounding bucket, so the strings come out identical.  But 
occasionally, the two values land on different sides of a decimal rounding 
boundary, and produce different decimal text strings.

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".

> 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.

> > > 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.  It has nothing to do with "POSIX incompatibilities".  It's 
actually mostly harmless in this context since the regression tests don't 
use SHM at all, 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.

Fred Wright