On 11/24/2016 12:42 AM, Jakub Jelinek wrote:
After reviewing a few more of the XALLOCAVEC calls in the affected
files I suspect that those to alloca(0) pointed out by the warning
may be just a subset that GCC happens to see thanks to constant
propagation. If that's so then changing this subset to
alloca(N + !N) or some such is probably not the right approach
because it will miss all the other calls where GCC doesn't see that
N is zero. I think the most robust solution is to do as Bernd
suggests: change XALLOCAVEC as shown above. That will let us
prevent any and all unsafe assumptions about the result of
alloca(0) being either non-null or distinct. The other approach
would be to change XALLOCAVEC to add 1 to the byte count. That
would be in line with what XMALLOC does.
I still fail to see why you want to change anything at least for
hosts where you know XALLOCAVEC is __builtin_alloca.
Show me one place which assumes the result of alloca (0) in gcc sources is
distinct, or non-NULL. For 0 elements the pointer simply isn't used.
And whether for the malloc based alloca it GCs or not really doesn't matter
for us.
I think for host/build, we ought to assume that alloca is
__builtin_alloca. I think we stopped supporting the
alloca-on-top-of-malloc host/build systems long ago.
But I still think we ought to be "clean" in regard to zero sized
allocations. It sounds like an assert may not be sufficient, so we need
to look at another approach.
Jeff
