Re: RFC: pass to warn on questionable uses of alloca().

[Szabolcs Nagy <szabolcs dot nagy at arm dot com>]

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.