tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: alloca again

On Wed, Oct 05, 2022 at 12:06:10 +0000, nia wrote:

> On Tue, Oct 04, 2022 at 12:21:08AM +0200, Joerg Sonnenberger wrote:
> > On Mon, Oct 03, 2022 at 12:31:42PM +0000, nia wrote:
> > > I'd argue that providing alloca(3) as anything except a compiler
> > > builtin is a bug, and that kind of thing should never be used.
> > 
> > Well, if you are in strict C/C++ standard mode, alloca should not exist
> > because it is not part of the standard. If you are in GNU-extended mode,
> > the builtin logic for it will trigger. Not leaking extra macros has its
> > advantage.
> Would you agree that we shouldn't have a definition for alloca in our
> headers since it should be handled by the compiler, then?

The compiler needs to see the declaration for the builtin handling to
kick in properly.  Without one you will get:

  warning: implicit declaration of function 'alloca' [-Wimplicit-function-declaration]
  warning: incompatible implicit declaration of built-in function 'alloca' [-Wbuiltin-declaration-mismatch]

with a wrong one you will get:

  warning: mismatch in return type of built-in function 'alloca'; expected 'void *' [-Wbuiltin-declaration-mismatch]


  warning: conflicting types for built-in function 'alloca'; expected 'void *(long unsigned int)' [-Wbuiltin-declaration-mismatch]


Home | Main Index | Thread Index | Old Index