Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Oscar Benjamin <oscar.j.benjamin@gmail.com>
Newsgroups: comp.lang.python
Subject: Re: Undefined behaviour in C [was Re: The Cost of Dynamism]
Date: Sun, 27 Mar 2016 22:16:40 +0100
Lines: 71
Message-ID: <mailman.95.1459113409.28225.python-list@python.org>
References: <mailman.8.1457732171.12893.python-list@python.org> <ncnkma$d1i$1@dont-email.me> <mailman.425.1458526280.12893.python-list@python.org> <56ef9787$0$1516$c3e8da3$5496439d@news.astraweb.com> <mailman.433.1458546438.12893.python-list@python.org> <56f02196$0$1588$c3e8da3$5496439d@news.astraweb.com> <mailman.29.1458713374.2244.python-list@python.org> <nctrak$rbh$1@dont-email.me> <mailman.45.1458730161.2244.python-list@python.org> <ncu691$4aq$1@dont-email.me> <mailman.78.1458789868.2244.python-list@python.org> <nd0oaa$rsb$1@dont-email.me> <56f42d9f$0$1618$c3e8da3$5496439d@news.astraweb.com> <nd1ggm$v4q$1@dont-email.me> <56f55e2e$0$1619$c3e8da3$5496439d@news.astraweb.com> <87wpoq1omm.fsf@elektro.pacujo.net> <56f5f81d$0$1585$c3e8da3$5496439d@news.astraweb.com> <87io0a6j1w.fsf@nightsong.com> <56f67ee3$0$1583$c3e8da3$5496439d@news.astraweb.com> <87twjs5tz2.fsf@nightsong.com> <56f78e74$0$1616$c3e8da3$5496439d@news.astraweb.com> <87zitj1yae.fsf@bsb.me.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
In-Reply-To: <87zitj1yae.fsf@bsb.me.uk>
Precedence: list
Xref: csiph.com comp.lang.python:105874

On 27 Mar 2016 23:11, "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote:
>
> Steven D'Aprano <steve@pearwood.info> writes:
>
> > On Sun, 27 Mar 2016 05:13 pm, Paul Rubin wrote:
> >
> >> Steven D'Aprano <steve@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