Re: Avoid alloca(0) when temporarily propagating operands during threading

[Jeff Law <law at redhat dot com>]

On 12/02/2016 10:58 AM, Jakub Jelinek wrote:
> On Thu, Dec 01, 2016 at 11:43:19PM -0700, Jeff Law wrote:
> > Martin's alloca work flagged this code as problematical.  Essentially if we
> > had a statement with no operands and the statement was not in the hash
> > table, then we could end up performing alloca (0), which is inadvisable.
>
> I still don't understand why it is inadvisable.  alloca(0) is not undefined
> behavior.  It can return NULL, or non-unique pointer, or a unique pointer,
> and/or cause freeing of already left alloca blocks (like any other alloca
> call).
> None of that is a problem here.  If num is 0, then copy is just set and
> never used.
> I expect most if not all gcc uses of alloca where the count can be 0 are
> like that.
It won't cause any problems in this and probably most instances, but 
leaving the code in its prior state is simply wrong from a maintenance 
standpoint.

I'd much rather have the code explicitly and safely handle the zero 
operands case so that if someone makes a change later they don't have to 
worry about whether or not they're accessing memory which was never 
allocated.

Additionally, it removes a false positive from the warning, thus making 
less noise.

It's not unlike the strictly unnecessary initializations we do to shut 
up -Wuninitialized.

Jeff