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

[Martin Sebor <msebor at gmail dot com>]

On 06/20/2016 03:41 PM, Jeff Law wrote:
> On 06/20/2016 08:56 AM, Joseph Myers wrote:
> > On Sat, 18 Jun 2016, Martin Sebor wrote:
> >
> > > the function regardless of the value of its argument).  At
> > > the same time, it seems that an even more reliable solution
> > > than pointing out potentially unsafe calls to the function
> > > and relying on users to modify their code to use malloc for
> > > large/unbounded allocations would be to let GCC do it for
> > > them automatically (i.e., in response to some other option,
> > > emit a call to malloc instead, and insert a call to free when
> > > appropriate).
> >
> > Note that such an option would not be usable for the original motivating
> > case of glibc, because in code that's meant to be async-signal-safe,
> > alloca and VLAs can be used, but malloc cannot.
> I've actually considered the other direction more viable.  Define the
> right set of constraints and let the compiler optimize from malloc/free
> to alloca.
>
> For the uses of alloca in glibc that have to be async-signal-safe, we
> should just leave those alone no matter what we may or may not be able
> to prove.

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.

Martin