[PATCH v2 00/14] Fix signal-unsafe logging

Peter Hutterer peter.hutterer at who-t.net
Sun Jun 3 21:20:54 PDT 2012

On Wed, Apr 11, 2012 at 06:33:26PM -0700, Chase Douglas wrote:
> On 04/11/2012 04:53 PM, Peter Hutterer wrote:
> > On Mon, Apr 09, 2012 at 11:17:26AM -0700, Chase Douglas wrote:
> > - the API is rather shocking, replacing one vararg function with a number of
> >   mixed calls makes it really hard to grep for the message.
> >   a poor man's printf parsing that searches for %d, %s and %x would help
> >   here.
> Variadic argument implementation is some of the blackest magic of C
> code, and varies a great deal even between architectures of glibc. I
> don't know if we can be sure that variadic arguments will always be
> signal safe. They aren't mentioned in the POSIX signal(7) man page as
> safe functions.
> I doubt we would actually support Interix SUA, for example, but it is
> POSIX compliant and its man page says va_* functions are not signal
> safe: http://www.suacommunity.com/man/3/varargs.3.html.
> > - given that input drivers almost always use signal-sensitive processing,
> >   making xf86IDrvMsg signal safe would go a long way 
> It's variadic, so I don't think that will be possible. I know there's
> bound to be some pain here that reaches device drivers, but I don't see
> a way around it.

sorry to pick this up so late. I've been banging my head against the wacom
driver, finding a good way to log debug messages while parsing events and
the crux of the matter is the vararg stuff. I went searching again and found
that signal(7) lists execle() and that function takes a variable number of
parameters. execle is a POSIX requirement, va_list and friends must be
vararg-compatible, which means we can have a normal implementation of the
log messaging functions.


More information about the xorg-devel mailing list