%m, #614

[James Browning]

On Sun, Aug 25, 2019 at 3:49 PM Hal Murray via devel <devel at ntpsec.org>
wrote:

> I think it should be fixed for the release, but I don't know how to do it.
>
> There used to be code in the msyslog processing that handled %m if it
> wasn't
> included in the local printf.  I'm guessing it was removed to eliminate
> warnings on some systems that don't support %m.
>
> All the %m cases were changed to use %s and strerror(errno).
>
> But that doesn't work with threads.  The NTS code uses threads.  (I think
> the
> DNS code avoided the problem by not doing any logging from the worker
> thread
> but I'd have to check to be sure.)
>
> Using strerror_r seems like the obvious solution, but there are 2
> variations
> to the API.  BSD only supports the XSI version.  On Linux, we get the GNU
> version.
>
> waf turns on _GNU_SOURCE
> wscript says:
>     # FIXME: We'd like this to be -D_POSIX_C_SOURCE=200809L
> -D_XOPEN_SOURCE=600
>     # rather than -D_GNU_SOURCE, but that runs into problems in two places:
>     # (1) The ISC net handling stuff, where struct in6_addr’ loses a
> member
>     # named s6_addr32 that the macros need, and (2) three BSD functions
>     # related to chroot jailing in the sandbox code.
>
> Is this the time to fix it?  This area is above my pay grade.
>
> -------
>
> Otherwise, the best approach I see would be to make a my_strerror_r that
> has
> the API we want.  I think that needs a configure time test to determine
> which
> version we get and a simple #ifdef in the implementation of
> my_strerror_r().
>
> Anybody got better ideas?
>
> Would it be better to go back to using %m and tolerate the warnings?  Does
> anybody remember which systems generated the warnings?  Was the %m code in
> msyslog thread safe?


A bad search through the git log suggests a clutch of commits in that
area by me in earlyish march and maybe one by you in late January.
previous to that there was a commit by Eric some time back and then
one by Stenn.

A search on gitlab points a smoking gun at me in merge request 964 and
issues 565, 536, 498 and other stuff I don't see at the moment.

No, I do not think it is time to fix it, next month however. I do not
have better ideas. I did have a patch that shushed the warnings on
clang and GCC and buried it. The warnings were on FreeBSD and Netbsd
IIUC. I don't think anything in msyslog was thread safe, but I have
been wrong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190825/ba00e858/attachment.htm>