Increment operator

[Kenneth Brody]

[snips]

main()
{
int i = 3;

i = i++;

printf("%d\n", i);
}

Undefined behaviour is not /required/ to be bizarre behaviour.
Incidentally, I ran the program at home and got the output: "a
suffusion of yellow".

No you didn't. You got 3 or 4.

Really? Could you please quote the part of the standard that requires the
code above to produce a result of either 3 or 4?

Really? Could you please quote the biblical verse that requires the
price of tea in China to be between $30 and $50 a ton?

Or:

How do you spell non-sequitor?

I see no non-sequitur here.

[Hoping I am reading the attributions correctly.]

Richard said "No you didn't. You got 3 or 4." in reply to the
[unattributed] statement that the other poster had gotten "a
suffusion of yellow" as the output. The definitiveness of
Richard's post must be based on something. The only source of
such definitiveness in this group is "The Standard". If he is
so absolutely sure that a C compiler _must_ have give one of
those two results, it must be because The Standard says it must.

So, a request for C&V is quite reasonable, IMHO.

Lacking such a reference, I take Richard's statement as a matter
of opinion, along the lines of "I believe that the odds are that
most compilers will probably cause the program to output '3' or
'4'". (And I happen the agree that "most" compilers "probably"
will do that. I do not believe that "all" "will".)

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Harald van =?UTF-8?B?RMSzaw==?=]

[RJH] Undefined behaviour is not /required/ to be bizarre
behaviour. Incidentally, I ran the program at home and got
the output: "a suffusion of yellow".

[RGR] No you didn't. You got 3 or 4.

[KB] Really? Could you please quote the part of the standard
that requires the code above to produce a result of either
3 or 4?

[RGR] Hardly likely to provide an "either or" is it?

The C Standard does actually require the implementation to choose
between two alternatives on occasion. This is not one of those
occasions.

Could you provide me any compiler where the output is NOT 3 or 4
please?

I have already shown output that is neither 3 nor 4, produced by the
program specified upthread when compiled using a conforming
implementation here at my home. Your inability to believe me is your
problem, not mine.

Indeed. I have a pretty good idea about the nature of the conforming
implementation you used; such an implementation would be reasonably
easy to obtain.

Figuring this out merely requires an understanding of what a
"conforming implementation" is.

To those who doubt this: I don't speak for Richard, but I suspect he
would have been willing to explain it to anyone who asked without
first accusing him of being a liar. (I'm curious about the details,
but I'm enjoying the mystery too much to ask.)

I don't know if this is the approach that Richard took but here is my
conforming (I think) implementation which produced similar results:

----
$ cat ub.c
#include <stdio.h>
int main(void)
{
int i = 3;
i = i++;
printf("%d\n", i);
return 0;
}

$ ./compile ub.c
ub.c: In function 'main':
ub.c:5: warning: operation on 'i' may be undefined

$ ./ub
a suffusion of yellow
----
$ cat nub.c
#include <stdio.h>
int main(void)
{
int i = 3;
i++;
printf("%d\n", i);
return 0;
}

$ ./compile nub.c

$ ./nub
4
----
$ cat compile
#!/bin/sh

outname=${1%\.*}

gcc -fsyntax-only -Wsequence-point "$1" 2>&1 | grep 'may be undefined'

/dev/null

if [ $? -eq 0 ]
then
gcc -Wall -ansi -pedantic -W -fsyntax-only "$1"
gcc -ansi -o "$outname" -x c - <<EOF
#include <stdio.h>
int main (void) { puts("a suffusion of yellow"); return 0; }
EOF
else
gcc -Wall -W -ansi -pedantic "$1" -o "$outname"
fi
----

There are obvious improvements that could be made such as passing
multiple arguments from "compile" to gcc but from what I can tell it
isn't any less conforming that gcc itself (unless of course gcc
incorrectly diagnoses possible undefined behavior).

The below program is strictly conforming:

#include <stdio.h>
int f(void)
{
int i = 3;
i = i++;
printf("%d\n", i);
return 0;
}
int main(void)
{
return 0;
}

Any compiler which makes this output "a suffusion of yellow" does not
conform to any C standard.

However, this implementation could be conforming:

#!/bin/sh
if ! diff "$1" buggy.c >/dev/null; then
gcc -std=c89 -pedantic -Wall -Wextra "$1"
else
gcc -std=c89 -pedantic -Wall -Wextra buggyreplacement.c
fi

 

[Kenneth Brody]

Harald van D?k wrote:
[...]

The below program is strictly conforming:

#include <stdio.h>
int f(void)
{
int i = 3;
i = i++;
printf("%d\n", i);
return 0;
}
int main(void)
{
return 0;
}

Any compiler which makes this output "a suffusion of yellow" does not
conform to any C standard.

[...]

I was under the impression that a compiler is allowed to refuse to
even compile a program which contains UB?

Are there any restrictions as to what the compiler can do, should
it be so inclined as to actually compile the code?

Does the Standard say anything about what a program must do if it
contains UB which does not get executed?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Harald van =?UTF-8?B?RMSzaw==?=]

Harald van D?k wrote:
[...]

The below program is strictly conforming:

#include <stdio.h>
int f(void)
{
int i = 3;
i = i++;
printf("%d\n", i);
return 0;
}
int main(void)
{
return 0;
}

Any compiler which makes this output "a suffusion of yellow" does not
conform to any C standard.

[...]

I was under the impression that a compiler is allowed to refuse to
even compile a program which contains UB?

Correct. However, this program contains no UB, because function f is never
executed, so the compiler is not allowed to refuse to compile the program.

Are there any restrictions as to what the compiler can do, should
it be so inclined as to actually compile the code?

Does the Standard say anything about what a program must do if it
contains UB which does not get executed?

The standard doesn't explicitly address it, but DR #109
<http://open-std.org/JTC1/SC22/WG14/www/docs/dr_109.html> does.

 

[Kelsey Bjarnason]

[snips]

Really? Could you please quote the biblical verse that requires the
price of tea in China to be between $30 and $50 a ton?

No, but then that doesn't apply. To assert the above produced a value of
3 or 4 requires imposition of restrictions on the possible output set.
Since the standard *explicitly* removes any such restrictions, your
attempts to assert that they exist is contrary to any realistic
expectation.

The most you could hope is that the compiler behaves in a predictable
manner based on physics, but then, that does not prevent answers other
than 3 or 4 occurring - nor does it prevent a compiler detecting certain
forms of UB and by design producing unusual results.

So for you to assert that the result was "3 or 4" requires a formal
requirement on the possible outputs, and the only place such a formal
requirement would exist would be in the standard - so please explain
where, in the standard, the results of the above are defined.

 

[Kelsey Bjarnason]

[snips]

Hardly likely to provide an "either or" is it?

Could you provide me any compiler where the output is NOT 3 or 4 please?

Not required. The code invokes UB, which means *any* result is
acceptable. Since the poster has asserted that a *specific* result (or
one of a specific set of results) are the only ones possible, it is up to
him to demonstrate this, based on the only applicable source of
requirements on program output - the standard. The same standard which
documents the behaviour as undefined and allows for *any* result when
invoking undefined behaviour.

 

[Kelsey Bjarnason]

[snips]

So, the following is a perfectly acceptable "C implementation" for the
above program (the one containing: i = i++)

#!/bin/sh
echo 'echo "a suffusion of yellow"' > /tmp/yellow

The above is, of course, not a conforming C implementation, since it
doesn't do the right thing with strictly conforming programs.

Err... the one produced by Robert is fine, as it only does the replacement
when an "undefined" condition arises and if not, passes the code,
unmodified, to gcc.

Net result, for anything with a certain class of issues, it produces "a
suffusion of yellow", whereas for strictly conforming code, it produces
the expected output.

It does exactly what it's supposed to do on proper code, and it does
exactly what it's allowed to do - anything at all - on code with UB. So
where, exactly, is the problem?

 

[Kenny McCormack]

[snips]

Hardly likely to provide an "either or" is it?

Could you provide me any compiler where the output is NOT 3 or 4 please?

Not required. The code invokes UB, which means *any* result is

Thanks for playing: Totally Missing the Point!

Carol has lovely parting gifts for you.

 

[Kenny McCormack]

[snips]

So, the following is a perfectly acceptable "C implementation" for the
above program (the one containing: i = i++)

#!/bin/sh
echo 'echo "a suffusion of yellow"' > /tmp/yellow

The above is, of course, not a conforming C implementation, since it
doesn't do the right thing with strictly conforming programs.

Err... the one produced by Robert is fine, as it only does the replacement
when an "undefined" condition arises and if not, passes the code,
unmodified, to gcc.

Net result, for anything with a certain class of issues, it produces "a
suffusion of yellow", whereas for strictly conforming code, it produces
the expected output.

It does exactly what it's supposed to do on proper code, and it does
exactly what it's allowed to do - anything at all - on code with UB. So
where, exactly, is the problem?

I have no problem. How about you?

 

[Kenny McCormack]

Really? Could you please quote the biblical verse that requires the
price of tea in China to be between $30 and $50 a ton?

No, but then that doesn't apply. To assert the above produced a value of[/QUOTE]

Thanks for playing: Totally Missing the Point!

Lovely parting gifts for you.

 

[CBFalconer]

.... snip ...

The below program is strictly conforming:

#include <stdio.h>
int f(void)
{
int i = 3;
i = i++;
printf("%d\n", i);
return 0;
}
int main(void)
{
return 0;
}

Any compiler which makes this output "a suffusion of yellow" does not
conform to any C standard.

No it isn't. The statement "i = i++;" triggers UB.

 

[Old Wolf]

Err... the one produced by Robert is fine, as it only does the replacement
when an "undefined" condition arises and if not, passes the code,
unmodified, to gcc.

Net result, for anything with a certain class of issues, it produces "a
suffusion of yellow", whereas for strictly conforming code, it produces
the expected output.

It does exactly what it's supposed to do on proper code, and it does
exactly what it's allowed to do - anything at all - on code with UB. So
where, exactly, is the problem?

Not quite; consider a program that produces that
diagnostic in a section of code that is not reached
until some condition is met. The compiler must
produce a program that is fully functional until
execution reaches the erroneous construct.

So the script is not a conforming implementation,
and I don't see any easy adjustment to make it so.

 

[Kelsey Bjarnason]

Not quite; consider a program that produces that
diagnostic in a section of code that is not reached
until some condition is met. The compiler must
produce a program that is fully functional until
execution reaches the erroneous construct.

I suspect you're thinking something along these lines:

while( condition )
{
if (x )
y = y++;
...
}

As long as x is zero, the UB never occurs, thus the code should behave
properly until x is nonzero and the y = y++ line gets executed.

I question that. Consider, the reasons for defining UB (among other
things) are, among other concerns, to allow compiler writers a certain
leeway in optimizing. Essentially, they have to produce correct code for
correct constructs but aren't under any requirements for incorrect
constructs.

Therefore it is entirely conceivable that the compiler, on seeing the y =
y++, completely hoses any and all code generation (possibly from that
point on, possibly across the entire set of generated code) and as a
result, no aspect of the code is expected to work properly, even if, at
runtime, x would never actually go non-zero.

Is there C&V that says that the compilation stage must produce correct
results even in the face of constructs invoking UB and that only runtime
is allowed to actually produce incorrect results, and then only after the
line is executed?

As I see it, the compiler could well see the like, get messed up and do an
optimization pass - or whatever - that completely messes things up all
over the place, so there would have to be a definite requirement in the
standard that compilation and runtime follow significantly different rules
in order for the example above to be acceptable until x's value changes.

Or did I misunderstand your intent entirely?

 

[Kelsey Bjarnason]

[snips]

Really? Could you please quote the part of the standard that requires the
code above to produce a result of either 3 or 4?

Hardly likely to provide an "either or" is it?

Could you provide me any compiler where the output is NOT 3 or 4 please?

Not required. The code invokes UB, which means *any* result is

Thanks for playing: Totally Missing the Point!

Er... the point was that the code invokes UB and therefore is allowed to
produce any result whatsoever.

Which bit of that did I miss?

 

[Kelsey Bjarnason]

No, but then that doesn't apply. To assert the above produced a value of

Thanks for playing: Totally Missing the Point![/QUOTE]

The point was that the code invokes UB, which means any result is
"correct", not just results of 3 or 4. Which part of this point did I
miss?

 

[Walter Roberson]

Is there C&V that says that the compilation stage must produce correct
results even in the face of constructs invoking UB and that only runtime
is allowed to actually produce incorrect results, and then only after the
line is executed?

In a parallel line in this thread, Harald wrote,

 

[Kenny McCormack]

The point was that the code invokes UB, which means any result is
"correct", not just results of 3 or 4. Which part of this point did I
miss?

By definition, people who miss the point are not able to understand the
point that they have missed. Therefore, I shan't bother explaining it
to you. I think most of us (those of us in category 3) can see how
ridiculous you look, however.

 

[Old Wolf]

In a parallel line in this thread, Harald wrote,

Thanks for clearing that up, I still wasn't 100% sure
that what I wrote was correct. I guess the relevant
line of that page is the last one:
"Because foo might never be called, the example given
must be successfully translated by a conforming implementation."

 

[Keith Thompson]

On Mon, 30 Jul 2007 21:17:18 +0000, Kenny McCormack wrote: [snip]
The point was that the code invokes UB, which means any result is
"correct", not just results of 3 or 4. Which part of this point did I
miss?

The point you missed is that KM is a troll. Please ignore him.

 

[Kenny McCormack]

On Mon, 30 Jul 2007 21:17:18 +0000, Kenny McCormack wrote: [snip]
The point was that the code invokes UB, which means any result is
"correct", not just results of 3 or 4. Which part of this point did I
miss?

The point you missed is that KM is a troll. Please ignore him.

Ahem. Contrarian. Get it right.