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