Re: Adding <alloca.h> ?

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On May 13, 22:37, Joerg Sonnenberger wrote:
} On Thu, May 13, 2021 at 09:58:50PM +0200, Jaromír DoleÄ?ek wrote:
} > Le jeu. 13 mai 2021 à 21:44, Joerg Sonnenberger <joerg%bec.de@localhost> a écrit :
} > > > No we don't, unless you are using PCC :D
} > > >
} > > > The block in <stdlib.h> only provides an alloca(3) prototype, and only
} > > > if the compiler already #defines alloca as __builtin_alloca.
} > > >
} > > > While this works for gcc in some -std modes (e.g. gnu++14), it does
} > > > not in others (c++14, c++11).
} > >
} > > Your analysis is wrong. We don't provide a prototype in standard modes
} > > as that violates the user request. The prototype is enough to trigger
} > > the builtin logic in GCC and Clang.
} > 
} > Allright.
} > 
} > Anyway, would it be wrong to add <alloca.h> which unconditionally
} > makes alloca() use the builtin, similar to what e.g. glibc (Linux) and
} > FreeBSD do, or is it fundamentally wrong doing so?
} 
} I don't see the point in it. The source is wrong to request strict C++14
} compatibility and then use an extension. Just because Linux folks do
} that wrong doesn't mean we should cater to their bugs.

     This comment reminds me of Henry Spencer's "All the World's
a VAX" comment:
https://www.brcline.com/blog/the-ten-commandments-for-c-programmers .
In a way, he is correct (adjusted for time of original posting).
However, the reality is that Linux sets the standard, whether we
like it or not.  There are situations where we are going to have
to bite the bullet and accept things that are impure.  Whether or
not this is one of those situations is current subject of debate.

}-- End of excerpt from Joerg Sonnenberger