This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: pass to warn on questionable uses of alloca().
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Martin Sebor <msebor at gmail dot com>, Jakub Jelinek <jakub at redhat dot com>, Jeff Law <law at redhat dot com>
- Cc: <nd at arm dot com>, Joseph Myers <joseph at codesourcery dot com>, Aldy Hernandez <aldyher at gmail dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 28 Jun 2016 17:52:02 +0100
- Subject: Re: RFC: pass to warn on questionable uses of alloca().
- Authentication-results: sourceware.org; auth=none
- Nodisclaimer: True
- References: <57626439 dot 7040501 at gmail dot com> <5765DF61 dot 9040200 at gmail dot com> <alpine dot DEB dot 2 dot 20 dot 1606201454241 dot 5028 at digraph dot polyomino dot org dot uk> <87a2d8f0-bdf4-4d5d-9059-54bf4e109ef8 at redhat dot com> <5769627E dot 1010104 at gmail dot com> <3127b3d0-bf29-cffa-75e2-ab9da4238b2c at redhat dot com> <20160621160046 dot GP7387 at tucnak dot redhat dot com> <576970CB dot 60206 at gmail dot com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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.