On 11/19/16 00:52, Martin Sebor wrote:
> On 11/18/2016 03:51 PM, Bernd Edlinger wrote:
>>  > of the builtin (the function is not declared without attribute
>>  > alloc_size, at least in Glibc, but GCC still expands it inline).
>>  > This is as simple as enclosing alloca in parentheses:
>>  >
>>  >   void *p = (alloca)(n);
>>  >
>>  > Ugly?  Perhaps.  One might say that code that does tricky or
>>
>> No. I doubt that will work, unless you use -ffreestanding on the
>> command line.
>
> It works because "__builtin_alloca" is distinct from "alloca" and
> the warning code can simply compare the strings, just as you say
> you did below.  It's not ideal and I would prefer to avoid it but
> I offer it as another solution if the performance overhead of
> (n + 1) is thought to be too high.
>

So far I thought the warning is trying to make no differences between
malloc, realloc and alloca.

I would say that using realloc(x,0) is for sure always wrong.
Nobody will object against a warning for that.

And yes, malloc(0) is unportable, but if the result is not used and
directly fed into free that should be no problem, but a warning would
be also helpful because it is unportable code.  But I hope that it is
not the same as with the false positive array bounds warnings where
the compiler first transforms the source code into something completely
different and then starts to warn about it.

Regarding alloca, there are probably three different forms.

First a function that is not a builtin but has the name "alloca"
like special_function_p understands it.  It has no attributes
unless the header mentions them.  Calling this function with
0 should not be warned about, right?

Then a function that has the name "alloca" and matches the signature
of the builtin "alloca" function.

And last a function that has the name "__builtin_alloca".

You can distinguish between these, and possibly only warn for
__builtin_alloca?  Note, that will depend on the way the glibc
header works.

Everything would be more easy if the glibc header would not do
that, and just use the alloca and no macro.  Then it would be
more natural to warn about alloca and not about __builtin_alloca,
because that is always implemented in a sensible way.

But even if the __builtin_alloca is called with 0, what do we
do with the result?  I mean any use of the value would be wrong.
So why is there a warning, when the value is not used?



Bernd.

Reply via email to