> | > | 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".
> | 
> | > There is no precedence for that that I know of. How about "_a"?
> | 
> | I prefer somewhat more longer suffix, but maybe "_ass" is obscene. ;)
> | How about "_ss" (signal safe), since the word asynchronous is not only
> | used for signals, but also I/Os and other things.

This sounds like a good idea.

> | And how about using "syslog_a" or "syslog_ss" as the async-signal-safe
> | variant of the syslog() function, instead of "syslog_r"?
> | I think people expect "syslog_r()" function behaves just like syslog()
> | except its extra argument and multithread-safeness, but the actual
> | implemetation have lots of differences, as written in
> 
> Well, the whole point of making syslog_r() async-signal-safe was because
> OpenBSD code assumes it is. Perhaps we keep syslog_r() as it is
> [async-signal-safe] and create a syslog_a() alias?

I vaguely worry about the appearance of async-signal-safe but not
reentrant functions, but otherwise it sounds good.