13 May
2005
13 May
'05
12:14 p.m.
It was thus said that the Great Dave Dunfield once stated:
*Ding ding ding* we have a winner!
> >> So, to tie this in with the Zen
Koan threads, what is the result of
> >>
> >> int i = 0;
> >> printf("%d %d %d\n",i++,i++,i++);
> >>
Officially this type of code (that which modifies an Lvalue multiple times
within the same sequence interval) invokes "undefined behaviour", which
means that the compiler can do "anything" - although highly unlikely, the
compiler can happily return 6 6 6 in this case, and leave the value of i at
31415 (or anything else) ... and be performing in a perfectly legal sense
- undefined operation is exactly that. The function performed is not defined
by the standard. On other words, it's not valid 'C'
(although it is syntactically correct, and
most compilers will accept it without a diagnostic).
At least the later version of GCC pick up on it:
[spc]tech1:/tmp>gcc --version
gcc (GCC) 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[spc]tech1:/tmp>gcc -Wall -ansi -pedantic -c t.c
t.c: In function `main':
t.c:8: warning: operation on `i' may be undefined
t.c:8: warning: operation on `i' may be undefined
[spc]tech1:/tmp>
I think the OP's point has been completely missed
(that a valid program is a
inherently very definitive and detailed specification).
What I was commenting on was this statement by John Hogerhuis:
I think the programming language is the most
succinct, clear, and unambiguous specification language imaginable.
Almost always each construct has one and only one interpretation.
Which really depends upon the language.
-spc (And C leaves some stuff underspecified like this to help compiler
writers wring performance out of compiled code ... )