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

| >>>>> On Fri, 27 Oct 2006 13:57:38 -0400,
|       christos@zoulas.com (Christos Zoulas) said:
| 
| > | > 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?
| 
| I prefer either
| - Only provide "syslog_ss" (or "syslog_a"), and do not provide "syslog_r".
| or
| - Provide both "syslog_ss" (or "syslog_a") and "syslog_r".
|   "syslog_r" does support floating point formats, "%m", and sends the
|   time of the event to syslogd(8) just like syslog(3).
|   "syslog_ss" does not support those things.

I prefer [2] (provide both). Now "_ss" or "_a" for the suffix? I am agnostic.

christos