Yo Fred!

On Mon, 17 Nov 2025 16:43:41 -0800 (PST)
Fred Wright <[email protected]> wrote:

> On Mon, 17 Nov 2025, Gary E. Miller wrote:
> 
> > Any updates?  You are the blocking item to release.  
> 
> Sorry.  Stuff on Saturday took longer than expected, and I was tied
> up all day yesterday.

All's well that ends well.

> > gpsd requires POSIX 2008.  What system do you have that does not
> > have that?  If this is the only POSIX 2008 issue, we can retore  the
> > strnlen() fallback.  
> 
> There's now one other - commit d672ea91 added a use of stpncpy(),
> which has the same availability issue.  BTW, the "p =" in the
> subsequent stpcpy() call is superfluous, though it's probably
> optimized out, anyway.

That's ugly.  A quick hack I intended to go back and fix someday...

> Those calls coud be handled on the Mac by using MacPorts
> legacy-support, but that wouldn't help BSD, and would require
> non-MacPorts builds to incorporate the additional dependency.  Just
> adding the fallback seems more straightforward.  The one I've added
> is a fairly simple version, that doesn't try to do multi-character
> parallelism for speed.  This use case isn't performance-critical,
> anyway.

Fair enough, but I already asked: What versions of what OS need this?

> The Qt detection and setup now allows Qt4, in the pecking order "6,
> 5, 4".

Good.

> Some '{0}' structure initializers are changed to '{{0}}' to avoid
> warnings from some compilers.

Odd.  I thought {0} was C99 Section  6.7.8.  What comppilers needed
the change?  We need to name and shame.

> Some format warnings in log messages are fixed.

And you did it  without giving me any new warnings.  That takes
some work to get right.
 
> The fallback for strnlen() is reinstated, and a fallback for
> stpncpy() is added.  Although these impact core code, they only
> affect cases that would otherwise have failed to build altogether.

stpncpy() is overkill for that one use.  But I don't want to look
at that hack again quite yet.

> The droproot error when (successfully) running as non-root is now
> just a warning, avoiding 194 error messages from the tests.

That will make Hal happy, but it makes support harder.  For some reason
a lot of gpsd users do not understand that chown() needs root, and
then complain when it fails.  IMHO, you should not be running the
regressions as a normal user.  But that is an eternal struggle.

> When having successfully opened a terminal line as non-root
> unsuccessfully attempts to unnecessarily change its permissions to
> allow future non-root opens, that's now just a warning instead of an
> error.

Also makes your life easier, and mine harder.  Next time a user complains
I'll consider changing it back.

> The bottom line is that none of these changes should have any impact
> on testing that others have already done.

They all work for me.  We'll need to give this one last test cycle
just in case.

> Most of my testing has been just building and running the regression 
> tests, but I did spot-check a few cases with a real receiver.  For
> the most part, receiver-dependent issues tend not to depend on the
> OS, CPU, or compiler.

Fair enough.

> Cases I tested:

Wow, that is a lot.  THanks!

> 10.5 ppc
> 10.5 ppc64
> 10.5-10.6 i386

OTOH, I sure hope we can stop supporting PPS and i386 soon.  I get
a lot of pushback from newbies trying to maintain support back that far.
Everyone under 30 years old think all integers are 64 bits.

> I'll push the changes now.

I got them.  They work fine for me.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        [email protected]  Tel:+1 541 382 8588

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

Attachment: pgpXLSjeGRvtq.pgp
Description: OpenPGP digital signature

Reply via email to