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

| Well, if we do not document it in the man page, we are free to change
| the implemetation of the 8 functions to not async-signal-safe.
| Of course we should change the implementation of syslog_ss (or syslog_a)
| at that time, though.

Fine, I will not document any of them (including {v,}snprintf_ss()).

| >      Aside from being reentrant, openlog_r(), closelog_r(), setlogmask_r,()
| >      syslog_r(), vsetlog_r() are also async-signal-safe.  Due to that fact,
| >      syslog_r() and vsyslog_r() have the following limitations:
| 
| >      1.   The format string cannot contain multi-byte character sequences.
| 
| >      2.   Floating point formats are not supported and print ``UnS''.
| 
| >      3.   The time of the event is not sent to syslogd(8).
| 
| >      4.   The error string in the %m format is not printed symbolically but as
| >           ``Error %d''.
| 
| >      Because of the above limitations the reentrant versions of the syslog(3)
| >      functions should only be used where reentrancy or async-signal-safety is
| >      required.  For more information about async-signal-safe functions and
| >      signal handlers, see signal(7).
| 
| I believe we should avoid the word "reentrant", and should use
| "MT-safe" or "multithread-safe" instead, because the word "reentrant"
| may mean async-signal-safe in some technical context.
| For example, Wikipedia (http://en.wikipedia.org/wiki/Reentrant) says:
| 	To be reentrant, a function must hold no static data, must not
| 	return a pointer to static data, must work only on the data
| 	provided to it by the caller, and must not call non-reentrant
| 	functions.
| Many POSIX "_r" functions are not reentrant in this Wikipedia's sense,
| and using the word "reentrant" in the man page may confuse users.

Ok, I have changed the wording to be multithread-safe in the syslog(3)
page and added syslog_ss and vsyslog_ss.

christos