This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 12/02/2016 10:58 AM, Jakub Jelinek wrote:
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.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.
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |