Subject: Re: syslog_r (Re: CVS commit: src/lib/libc)
To: None <tech-userlevel@netbsd.org>
From: Christos Zoulas <christos@astron.com>
List: tech-userlevel
Date: 10/26/2006 10:29:27
In article <17728.29440.152745.85447@srapc2586.sra.co.jp>,
SODA Noriyuki  <soda@sra.co.jp> wrote:
>>>>>> On Thu, 26 Oct 2006 03:52:41 -0400 (EDT),
>      der Mouse <mouse@Rodents.Montreal.QC.CA> said:
>
>>> The OpenBSD documentation is wrong.
>>> For example, the snprintf() function indirectly calls __dtoa() via
>>> following path:
>>> snprintf() -> vfprintf() -> cvt() -> __dtoa()
>>> And the __dtoa() implemenation modifies lots of static data [...]
>
>> Perhaps snprintf *can* end up calling __dtoa.  But does it actually do
>> so when called the way syslog_r calls it?  (This is an honest question;
>> I don't know the answer, but it seems at least plausible that syslog_r
>> may take care to call snprintf only in ways that end up being
>> signal-safe.)
>
>OpenBSD man page doesn't say that floating point format shoundn't be
>used in signal handlers, and their syslog_r() implementation doesn't
>reject floating point format.  So, it doesn't take care of it at all.
>
>Also, as yamt said, the vfprintf() function is calling locale stuff
>(e.g. mbrtowc()) in its main loop to parse the format string.  And
>such stuff isn't documented as async-singal-safe either.

Is it worth having a small vsnprintf() that is async-signal-safe?

christos