%m, #614

[Hal Murray]

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?


-- 
These are my opinions.  I hate spam.