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

[Jakub Jelinek <jakub at redhat dot com>]

On Fri, Dec 02, 2016 at 11:13:29AM -0700, Jeff Law wrote:
> >But -Wuninitialized also found tons of real-world bugs.  Do we have a single
> >real-world example where such a warning would actually be useful (as in,
> >there would be an actual bug)?  Otherwise we are adding workarounds for a
> >warning that just forces people to add those workarounds, but doesn't
> >improve code in the wild in any way.
> Have you looked in depth at the lto.c issue it flagged?  I can't prove that
> one is safe.

If you mean the
      tree *map = XALLOCAVEC (tree, 2 * len);
call, then I strongly doubt it can actually ever be called with len == 0.
There is
  tree_scc *scc
    = (tree_scc *) alloca (sizeof (tree_scc) + (len - 1) * sizeof (tree));
a few lines above this and len is unsigned int, therefore for len 0 this
will try to (on 64-bit host) alloca (32 + 0xffffffff * 4UL), i.e. alloca
(0x40000001cUL) and I'm pretty sure on most hosts alloca of 16GB won't
really work.

Even if this succeeded for whatever reason, what problem do you see with
map = alloca (0)?

> And more generally, an under-sized allocation is a security risk.  We should

Sure.  But I really don't see 0 as being special in any way.  We do
support zero sized arrays and IMNSHO we want to support 0 sized alloca, it
is very much the same thing.  We also do support VLAs with 0 size.

	Jakub