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