<div dir="ltr"><div dir="ltr">On Sun, Aug 25, 2019 at 3:49 PM Hal Murray via devel <<a href="mailto:devel@ntpsec.org">devel@ntpsec.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think it should be fixed for the release, but I don't know how to do it.<br>
<br>
There used to be code in the msyslog processing that handled %m if it wasn't <br>
included in the local printf.  I'm guessing it was removed to eliminate <br>
warnings on some systems that don't support %m.<br>
<br>
All the %m cases were changed to use %s and strerror(errno).<br>
<br>
But that doesn't work with threads.  The NTS code uses threads.  (I think the <br>
DNS code avoided the problem by not doing any logging from the worker thread <br>
but I'd have to check to be sure.)<br>
<br>
Using strerror_r seems like the obvious solution, but there are 2 variations <br>
to the API.  BSD only supports the XSI version.  On Linux, we get the GNU <br>
version.<br>
<br>
waf turns on _GNU_SOURCE<br>
wscript says:<br>
    # FIXME: We'd like this to be -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=600<br>
    # rather than -D_GNU_SOURCE, but that runs into problems in two places:<br>
    # (1) The ISC net handling stuff, where struct in6_addr’ loses a member<br>
    # named s6_addr32 that the macros need, and (2) three BSD functions<br>
    # related to chroot jailing in the sandbox code.<br>
<br>
Is this the time to fix it?  This area is above my pay grade.<br>
<br>
-------<br>
<br>
Otherwise, the best approach I see would be to make a my_strerror_r that has <br>
the API we want.  I think that needs a configure time test to determine which <br>
version we get and a simple #ifdef in the implementation of my_strerror_r().<br>
<br>
Anybody got better ideas?<br>
<br>
Would it be better to go back to using %m and tolerate the warnings?  Does <br>
anybody remember which systems generated the warnings?  Was the %m code in <br>
msyslog thread safe?</blockquote><div> </div>A bad search through the git log suggests a clutch of commits in that<br>area by me in earlyish march and maybe one by you in late January.<br>previous to that there was a commit by Eric some time back and then<br>one by Stenn.<br><br>A search on gitlab points a smoking gun at me in merge request 964 and<br>issues 565, 536, 498 and other stuff I don't see at the moment.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">No, I do not think it is time to fix it, next month however. I do not<br>have better ideas. I did have a patch that shushed the warnings on<br>clang and GCC and buried it. The warnings were on FreeBSD and Netbsd<br>IIUC. I don't think anything in msyslog was thread safe, but I have<br>been wrong.<br></div></div>