Subject: Re: syslog_r (Re: CVS commit: src/lib/libc)
To: None <firstname.lastname@example.org>
From: James K. Lowden <email@example.com>
Date: 10/27/2006 19:44:03
SODA Noriyuki wrote:
> 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
> If we'd like to provide an async-signal-safe variant of function,
> we should use a suffix other than "_r".
I don't understand this fetish about matching the name of something to its
safeness. The _r functions exist not because the name implies something,
but because their non-reentrant ancestors already existed and were
unusable with threads. New functions had to be invented, the interface
changed, etc. C has no namespaces, so _r was tacked on.
It seems to me perfect need not be the enemy of the good. If Christos
commits syslog_r as is, we get something we didn't have before. Nothing
prevents us from documenting its shortcomings or improving it later.
Unless we expect the proposed syslog_ss (or _a) function to always differ
from syslog_r, we should just stick with the _r convention and document
syslog_r's limitations. Someone who wants to fix it, can. If you're
writing a signal handler, you have reason to be careful and are expected
not to assume problems away.
Maybe one day all the _r functions will be usable in signal handlers.
Maybe some can never be; I don't know. I don't see that as a reason to
invent a new naming convention. When you write your handler, use what's
safe. Don't look for memset_ss(3). RTFM and caveat programmer.
Am I missing something?