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.
I disagree. At a minimum, the return value of malloc(0) is
implementation-defined and so relying on it being either null
or non-null is non-portable and can be a source of subtle bugs.
But malloc(0) has also been known to result from unsigned overflow
which has led to vulnerabilities and exploits (famously by the JPG
COM vulnerability exploit, but there are plenty of others, including
for instance CVE-2016-2851). Much academic research has been devoted
to this problem and to solutions to detect and prevent it.
The following paper has some good background and references:
https://www.usenix.org/legacy/event/woot10/tech/full_papers/Vanegue.pdf
Coding standards rules have been developed requiring conforming
software to avoid allocating zero bytes for these reasons. TS
1796, the C Secure Coding Rules technical specification, has such
a requirement. It was derived from the CERT C Secure Coding rule
MEM04-C. Beware of zero-length allocations:
https://www.securecoding.cert.org/confluence/x/GQI
The same argument applies to alloca(0) with the added caveat that,
unlike with the other allocation functions, a non-null return value
need not be distinct.
In the absence of a policy or guidelines it's a matter of opinion
whether or not this warning belongs in either -Wall or -Wextra.
Based on the severity of the problems that allocating zero size
has been linked to I think it could be successfully argued that
it should be in -Wall (the problems are obviously more serious
than those that have ever been associated with the -Wunused-type
warnings, for example). I put it in -Wextra only because I was
trying to be sensitive to the "no false positive" argument.
All this said, before debating the fine details of under which
conditions each of the new warninsg should be enabled, I was
hoping to get comments on the meat of the patch that implements
the warnings.
Martin
