SODA Noriyuki wrote:
> 
> Using the "_r" suffix for async-signal-safe functions is a bad idea,
> because other "_r" functions are not async-signal-safe, but merely
> multithread-safe, and our snprintf() and vsnprintf() are already
> multithread-safe.
> 
> If we'd like to provide an async-signal-safe variant of function,
> we should use a suffix other than "_r".

I don't understand this fetish about matching the name of something to its
safeness.  The _r functions exist not because the name implies something,
but because their non-reentrant ancestors already existed and were
unusable with threads.  New functions had to be invented, the interface
changed, etc.  C has no namespaces, so _r was tacked on.  

It seems to me perfect need not be the enemy of the good.  If Christos
commits syslog_r as is, we get something we didn't have before.  Nothing
prevents us from documenting its shortcomings or improving it later.  

Unless we expect the proposed syslog_ss (or _a) function to always differ
from syslog_r, we should just stick with the _r convention and document
syslog_r's limitations.  Someone who wants to fix it, can.  If you're
writing a signal handler, you have reason to be careful and are expected
not to assume problems away.  

Maybe one day all the _r functions will be usable in signal handlers. 
Maybe some can never be; I don't know.  I don't see that as a reason to
invent a new naming convention.  When you write your handler, use what's
safe.  Don't look for memset_ss(3).  RTFM and caveat programmer.  

Am I missing something?  

--jkl