On Oct 28,  2:53am, soda@sra.co.jp (SODA Noriyuki) wrote:
-- Subject: Re: syslog_r (Re: CVS commit: src/lib/libc)

| >>>>> On Fri, 27 Oct 2006 13:33:45 -0400,
|       christos@zoulas.com (Christos Zoulas) said:
| 
| > | 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.

Heh, I am fine with _ss, or _a.

| 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?

christos