On 11/17/2016 05:32 PM, Martin Sebor wrote:
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:
I have the "advantage" of being a GCC gray beard and had the misfortune
of maintaining a system that had one of those allocas (hpux) *and*
having to debug heap exhaustions in GCC that would occur due to this
kind of construct
for (some large number of iterations)
frobit (...)
Where frobit would allocate a metric ton of stuff with alloca.
Note the calls to alloca down in frobit would all appear to be at the
same stack depth (alloca literally recorded the SP value and the PA was
a fixed frame target). So the calls to alloca within frobit wouldn't
deallocate anything.
http://www.qnx.com/developers/docs/6.5.0SP1.update/com.qnx.doc.neutrino_lib_ref/a/alloca.html
Their GCC-derived compilers apparently enable it with -fno-builtins.
Right.
That said, I don't view this as reason to exclude the warning from
-Wextra. The vendor-provided compilers are obviously customized
versions of GCC with their own features, including their own set
of options and warnings. It shouldn't stop us from enabling those
we expect to be useful to the typical GCC user on typical targets,
and especially those that can help expose sources of common bugs.
Recognizing I'm preaching to choir here: Calling alloca with any
argument is considered dangerous enough to be discouraged in most
man pages. Alloca(0) is a potentially dangerous corner case of
an already dangerous API. It seems at least as problematic as
any of the warnings already in -Wextra, and I'd say as many in
-Wall.
Right. We're well in the "living dangerously" space. But I could claim
that on one of these targets, warning about an alloca (0) would likely
result in a developer removing it or forcing it to allocate some small
amount of space to shut up the warning. That in turn runs the risk of
making the target code more prone to heap exhaustion and possibly less
secure, particularly if the developer isn't aware of the special nature
of alloca (0).
Even on systems with this unusual alloca implementation, since
alloca(0) is special (and expensive), warning on such calls would
likely be useful. In fact, since calling alloca(0) in these
environments is actually important, warning on them coukd help
detect their unintended absence. The few such calls that are
intended can be easily tweaked to suppress the warning.
It certainly is special and often expensive. But I'd come back to the
likely behavior of the developer. I suspect unless there's a comment
indicating the alloca (0) is intentional, they're likely to just remove it.
So I see both sides here and I'm not sure what the best path forward
should be.
jeff
