On 21/06/16 17:52, Martin Sebor wrote: > On 06/21/2016 10:00 AM, Jakub Jelinek wrote: >> On Tue, Jun 21, 2016 at 09:57:59AM -0600, Jeff Law wrote: >>>> Would a new attribute to annotate async-signal safe functions >>>> help? I envision that the attribute on a function definition >>>> would turn off the alloca/VLA to malloc transformation, and >>>> could also diagnose calls to other function whose declarations >>>> were not also declared async-signal safe with the same >>>> attribute. >>> It's probably a good idea -- there's enough "special" stuff with those >>> functions that having a way to mark them is useful. >>> >>> In fact, given the attribute, we ought to be able to build warnings around >>> multiple constructs that are not safe in that context. >> >> What about functions that are meant to be async-signal safe only for certain >> arguments or under some other conditions? >> Automatically turning VLAs or alloca into malloc/free would break those. > > I imagine in those unusual cases the author of such a function > would have to disable the transformation explicitly, either by > using the command line option it was under, or via the equivalent > pragma. > > But I wouldn't expect such cases to be common. I can't think of > any POSIX function that's conditionally async-signal safe. In > fact, by my reading, the POSIX definition of an async-signal safe > function prohibits it: > > Async-Signal-Safe Function > A function that may be invoked, without restriction, from > signal-catching functions. No function is async-signal-safe > unless explicitly described as such. > > Joseph would have a better idea whether there are any functions > in Glibc that are conditionally async-signal safe. >
in musl libc snprintf and sscanf are (mostly) as-safe. posix scanf has the 'm' assignment-allocation character which must use malloc and floating-point formatting may use fp arithmetics (which may not be as-safe because the fenv is unspecified at signal handler entry and has to be saved/restored if it may be modified). so as-safety depends on the format specifier. this is not required by any standard, but can be useful for e.g. debugging as-safe contexts with dprintf.
