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