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.
Martin
