On 11/18/2016 11:46 AM, Jeff Law wrote:
On 11/18/2016 12:58 AM, Jakub Jelinek wrote:
On Thu, Nov 17, 2016 at 05:32:31PM -0700, Martin Sebor wrote:
The point is warning on an alloca (0) may not be as clear cut as it
might seem. It's probably a reasonable thing to do on the host, but on
a target, which might be embedded and explicitly overriding the builtin
alloca, warning on alloca (0) is less of a slam dunk.
I confess I haven't heard of such an implementation before but after
some searching I have managed to find a few examples of it online,
such as in QNX or in the BlackBerry SDK, or in the GCC shipped by
Texas Instruments. For instance:
In the libiberty/alloca.c, I don't see anything special about alloca (0).
Yes, alloca (0) reclaims garbage, but so does alloca (1) and alloca
(4035).
alloca (0) just returns NULL after it. The diffutils link is the same
alloca.c as in libiberty. Returning NULL or returning a non-unique
pointer
for alloca (0) is just fine, it is the same thing as returning NULL or
returning a non-unique pointer from malloc (0). We definitely don't want
to warn for malloc (0), and IMNSHO don't want to warn for alloca (0),
because it behaves the same.
Maybe that's the key. We don't want to warn for
alloca (0);
But we should warn for
whatever = alloca (0);
The former is a clear request for GC of the alloca space. The latter it
much more likely a request for space where something went wrong
computing the amount of space.
That makes sense to me. In fact, it already works this way, though
not thanks to anything I did.
GCC optimizes calls to alloca away when their return value isn't used
so they don't trigger the warning. With -fno-builtin-alloca (and with
the Glibc alloca macro suppressed), a call to alloca(0) does not emit
the warning because Glibc alloca isn't declared with attribute
alloc_size (or any other attribute except C++ nothrow).
Only calls to the built-in whose return value is used do trigger it,
whether the argument is a literal zero or the result of constant
propagation.
Martin
