https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98055

--- Comment #5 from Paul Smith <psmith at gnu dot org> ---
IMO that response is missing the point.  This bug should be reopened and
resolved by removing this attribute from the __builtin_alloca function in GCC. 
That's all that's needed: there's no need for more complexity.

First, there's no need to add this attribute to alloca(): it's has virtually no
useful effect.  The chance that it actually catches a noticeable bug is almost
nil; any incorrect result that was more severe than reserving more stack than
was strictly necessary (actually failing to assign to a variable where it was
needed) would be obvious.

Second, alloca() is not just GCC's __builtin_alloca().  There are other
implementations, that behave differently than __builtin_alloca() and in those
implementations calling alloca() without using the return value is a valid and
useful thing to do.  I agree that it should not be up to GCC to try to suggest
portability options and am not suggesting it should do that.  However by adding
this attribute GCC is actively and affirmatively working _AGAINST_ portability.

The GCC docs say:

> warn_unused_result
> The warn_unused_result attribute causes a warning to be emitted if a caller
> of the function with this attribute does not use its return value. This is
> useful for functions where not checking the result is either a security
> problem or always a bug, such as realloc.

Using alloca() without checking the result is not a security problem, and it is
not always a bug as I've explained.  If it were the case that a commonly-used
malloc() replacement required calling malloc(0) (and not using the return
value) periodically for proper functioning, then absolutely GCC should clearly
not emit a warning for that usage even though GCC's malloc() doesn't work that
way, because otherwise it's hard to write code that doesn't depend on a
particular compiler.

Put more simply, I have this code in my program:

    alloca (0);

I need that line there so things work properly on compilers that don't provide
alloca().

How do you suggest I compile with GCC without either (a) forgoing this warning
everywhere or (b) adding a lot of pragma boilerplate to allow me to disable the
warning for this line or (c) creating a hack such as:

    { void *__p = alloca (0); (void) __p; }

Is there some preprocessor magic that lets me know that I'm using GCC's
__builtin_alloc so I can avoid calling alloca(0) in that situation?  I can't
think of one myself.

Reply via email to