[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: snprintf(3) and friends async-signal safety?
On 22.12.2010 19:23, Joerg Sonnenberger wrote:
> On Wed, Dec 22, 2010 at 08:13:21PM +0200, Jean-Yves Migeon wrote:
>> On Wed, 22 Dec 2010 16:46:02 +0000 (UTC), christos%astron.com@localhost
>> (Christos Zoulas) wrote:
>>>> Question is: is it really safe to use it in a signal handler inside
>>> It is not and this is why we have vsnprintf_ss() but that does not
>>> floating point formats.
>> That is not portable I guess -- and I don't see many executables
>> using snprintf_ss().
>> Now that I have raised that point, should I fix dd(1) to:
>> - use snprintf_ss() functions,
>> - use a volatile sig_atomic_t and put a call to summary() in the
>> input loop (that will cause delay to output, but it also fixes
>> asynchronous access when reading statistics)
>> - leave it as-is (don't care)
> I prfer the second, but make sure that the SIGINFO interrupt is marked
> as not restarting.
I prefer second option too, and worked with that in mind.
Why mark SIGINFO without SA_RESTART? Reads may fail with EINTR.
Main Index |
Thread Index |