What Every C Programmer Should Know About Undefined Behavior (2011)

Re:What Every C Programmer Should Know About Undefined Behav... by fstd on Thursday January 05, 2017 @09:02AM (#13327122)

if P does not point to valid memory, then dereferencing it is UB. Therefore, the compiler is at liberty to do whatever it wants (whether or not that is a good idea is irrelevant for the purposes of this consideration).

If the compiler knows that this is undefined, then you have already broken your end of the deal and therefore the compiler is free to break their end of the deal.

Therefore, eliminating the line is completely okay and the only think broken there is the code.

[ Parent | on HN ]

Re:What Every C Programmer Should Know About Undefined Behav... by 0xcde4c3db on Thursday January 05, 2017 @09:51AM (#13327479)

> if P does not point to valid memory, then dereferencing it is UB

IIRC, simply making P point to anything other than an object or 1 past the end of an array is already UB. I suspect that this is because some architectures have dedicated address registers and can take an exception when an invalid address is loaded/calculated instead of doing it when the memory access happens.

[ Parent | on HN ]

Re:What Every C Programmer Should Know About Undefined Behav... by lmm on Thursday January 05, 2017 @09:58AM (#13327535)

> IIRC, simply making P point to anything other than an object or 1 past the end of an array is already UB.

I don't think this is true in the strict sense you're describing it. Certainly forming a null pointer isn't UB as I understand it, only dereferencing one.

[ Parent | on HN ]

Re:What Every C Programmer Should Know About Undefined Behav... by 0xcde4c3db on Thursday January 05, 2017 @10:28AM (#13327831)

Yes, NULL is another exception that I forgot. I'm not sure this is ever explicitly stated as a distinct rule in the standard, but it seems to be implied by various arithmetic and conversion operations on pointers being UB if the result doesn't point to a valid object.

[ Parent | on HN ]