The "as-if rule"

[Stefan Ram]

Although it generally seems to be taken for granted that there
is an "as-if rule" in ISO/IEC 9899:1999 (E), there seems to be
no single place in ISO/IEC 9899:1999 (E) where this is explicitly
given in the normative part? (That is, no chapter and verse?)

 

[Keith Thompson]

Although it generally seems to be taken for granted that there
is an "as-if rule" in ISO/IEC 9899:1999 (E), there seems to be
no single place in ISO/IEC 9899:1999 (E) where this is explicitly
given in the normative part? (That is, no chapter and verse?)

The only mention of "as-if rule" is in the index. The entry points to
5.1.2.3, which is the section on "Program execution". Paragraph 3
permits the elimination of dead code in expressions. Paragraph 5
discusses the "least requirements on a conforming implementation",
implying that an implementation is not required to go beyond those
requirements. To summarize:

Volatile objects must be stable at sequence points.

Data written to files must be consistent with what would have been
written according to the abstract semantics.

Interaction with interactive devices must take place properly (so,
for example, a prompt appears before the program waits for input,
as long as it's properly flushed).

That leaves a lot of room for deleting and rearranging code.

 

[Walter Banks]

Although it generally seems to be taken for granted that there
is an "as-if rule" in ISO/IEC 9899:1999 (E), there seems to be
no single place in ISO/IEC 9899:1999 (E) where this is explicitly
given in the normative part? (That is, no chapter and verse?)

Stefan,

Besides Keith's comments.

The "as if" rules is frequently a part of committee discussions both
when they are seated and off line discussions.

It is generally taken to mean that C compilers must behave as
if they were implemented according to the standard but the
implementor is free make implementation choices "as long" as
the resulting behaviour does not change.

The most common examples are casting to a larger integer size
does not need to be done if the statement result is the same.
Adding two 8 bit chars and storing the result to a char can
be done without the casts to and from int.

Regards,

 

[Keith Thompson]

Stefan,

Besides Keith's comments.

The "as if" rules is frequently a part of committee discussions both
when they are seated and off line discussions.

It is generally taken to mean that C compilers must behave as
if they were implemented according to the standard but the
implementor is free make implementation choices "as long" as
the resulting behaviour does not change.

Or if the behavior was undefined in the first place.

The most common examples are casting to a larger integer size
does not need to be done if the statement result is the same.
Adding two 8 bit chars and storing the result to a char can
be done without the casts to and from int.

Um, probably.

Suppose plain char is signed, and CHAR_BIT==8. Consider:

char x = 100;
char y = 100;
char z = x + y;

Following the abstract machine semantics, the values of x and y are
converted from char to int via the "usual arithmetic conversions",
then they're added, yielding the int value 200, then that result is
converted to char. Since 200 exceeds CHAR_MAX, "either the result is
implementation-defined or an implementation-defined signal is raised"
(C99 6.3.1.3p3).

If the addition is done in type char, without promotion to int, then
the overflow causes the behavior of the addition to be undefined.
If the undefined behavior, say, causes the program to crash, then
the transformation changes the visible behavior of the program and
is therefore not allowed.

Of course the behavior isn't necessarily undefined as far as the
compiler is concerned. The compiler is free to take advantage of
its knowledge of how an overflowing addition behaves. On a typical
modern system, z will end up with the value -56 regardless of how
it's computed.

 

[Ian Collins]

Um, probably.

Suppose plain char is signed, and CHAR_BIT==8. Consider:

char x = 100;
char y = 100;
char z = x + y;

Of course the behavior isn't necessarily undefined as far as the
compiler is concerned. The compiler is free to take advantage of
its knowledge of how an overflowing addition behaves. On a typical
modern system, z will end up with the value -56 regardless of how
it's computed.

Isn't that the point Water was making?

 

[Keith Thompson]

Isn't that the point Water was making?

Yes, pretty much. I was just pointing out that there might
be odd systems on which that particular optimization is unsafe.
For example, if the CPU's 8-bit signed add instruction saturates on
overflow, so 100+100==127, but int-to-char conversion discards all
but the low-order 8 bits, so 100+100==-56, then the generated code
would actually have to convert the operands to int and the result
back to char.

As Walter wrote upthread:
| It is generally taken to mean that C compilers must behave as
| if they were implemented according to the standard but the
| implementor is free make implementation choices "as long" as
| the resulting behaviour does not change.

That last requirement is perhaps not as simple as it might seem at
first glance.

 

[Ian Collins]

Yes, pretty much. I was just pointing out that there might
be odd systems on which that particular optimization is unsafe.

Then the as-if rule outlined below would not apply. I think this is a
circular argument!

 

[Frank]

Then the as-if rule outlined below would not apply. I think this is a
circular argument!

One used to say that it "begged the question." In recent years, this
expression has changed meaning from indicating a logical situation
wherein one has, "if A, then A," and now it means "something that
motivates another question." It's a favorite expression of talking
heads on the tube.