Subject: Re: syslog_r (Re: CVS commit: src/lib/libc)
To: Christos Zoulas <email@example.com>
From: SODA Noriyuki <firstname.lastname@example.org>
Date: 10/28/2006 02:53:04
>>>>> On Fri, 27 Oct 2006 13:33:45 -0400,
email@example.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.
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
(not delivered to the mailing list yet).