On 27 Mar 2016 23:11, "Ben Bacarisse" <ben.use...@bsb.me.uk> wrote: > > Steven D'Aprano <st...@pearwood.info> writes: > > > On Sun, 27 Mar 2016 05:13 pm, Paul Rubin wrote: > > > >> Steven D'Aprano <st...@pearwood.info> writes: > >>> For example, would you consider that this isolated C code is > >>> "meaningless"? > >>> int i = n + 1; > >> > >> It's meaningful as long as n is in a certain range of values so there's > >> no overflow. > >> > >>> But according to the standard, it's "meaningless", since it might > >>> overflow, and signed int overflow is Undefined Behaviour. > >> > >> No it's not meaningless if it "might" overflow, it's meaningless if it > >> -does- overflow, > > > > No! That's exactly wrong! > > > > Paul, thank you for inadvertently proving the point I am trying to get > > across. People, even experienced C coders, simply don't understand what the > > C standard says and what C compilers can and will do. > > > > If the C compiler cannot prove that n is strictly less than MAXINT (or is > > that spelled INT_MAX?), > > (the latter) > > > the *entire program* (or at least the bits reachable from this line, > > in both directions) is Undefined, and the compiler has no obligations > > at all. > > If I understand you correctly, you are claiming that in this program > > #include <stdio.h> > > int main(int argc, char **argv) > { > int n = argc > 1 ? atoi(argv[1]) : 0; > int i = n + 1; // not needed but used because it's the line in question > printf("Hello world\n"); > } > > everything after "int i = n + 1;" is undefined because the compiler > can't prove that n is strictly less than INT_MAX.
Although Steve is incorrect to say that everything is undefined just because the compiler can't prove that n != INT_MAX one thing that he is right about is that undefined behaviour applies to the whole program. So if the n+1 does lead to undefined behaviour (i.e. if n == INT_MAX) then the behaviour is also undefined *before* that line. If we change the line to INT_MAX+1 then a compiler is free to do whatever it likes with the *entire* program. In practice what this means is that an optimising compiler can see n+1 and then optimise using the assumption that n!=INT_MAX (since there are *zero* constraints on the behaviour of the *entire* program if that assumption is broken). This optimisation could for example remove an if(n==INT_MAX) block as dead code even if the check occurs *before* the line that involves n+1 which can be surprising. Of course if the check is used to conditionally execute n+1 then the assumption cannot be applied by the optimiser so it's still entirely possible to avoid this particular undefined behaviour. -- Oscar -- https://mail.python.org/mailman/listinfo/python-list