On Sun, Aug 25, 2019 at 3:49 PM Hal Murray via devel <devel@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.
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
