On 06/03/2012 09:20 PM, Peter Hutterer wrote: > 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.
Your logic seems sound, albeit not an exceptionally strong proof that varargs are always signal safe :). At this point, I don't have the time to rewrite the patches again. Can I hand them off to you to finish? -- Chase _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
