Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > The "as-if rule"

Reply
Thread Tools

The "as-if rule"

 
 
Stefan Ram
Guest
Posts: n/a
 
      01-08-2010
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?)

 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      01-08-2010
http://www.velocityreviews.com/forums/(E-Mail Removed)-berlin.de (Stefan Ram) writes:
> 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.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Walter Banks
Guest
Posts: n/a
 
      01-08-2010


Stefan Ram wrote:

> 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,

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com





 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-08-2010
Walter Banks <(E-Mail Removed)> writes:
> Stefan Ram wrote:
>
>> 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.


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.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      01-08-2010
Keith Thompson wrote:
> Walter Banks <(E-Mail Removed)> writes:
>
>> 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;


<snip>

> 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?

--
Ian Collins
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-08-2010
Ian Collins <(E-Mail Removed)> writes:
> Keith Thompson wrote:
>> Walter Banks <(E-Mail Removed)> writes:
>>
>>> 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;

>
> <snip>
>
>> 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?


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.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      01-08-2010
Keith Thompson wrote:
> Ian Collins <(E-Mail Removed)> writes:
>> Keith Thompson wrote:
>>> Walter Banks <(E-Mail Removed)> writes:
>>>
>>>> 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;

>> <snip>
>>
>>> 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?

>
> 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!

> 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.


--
Ian Collins
 
Reply With Quote
 
Frank
Guest
Posts: n/a
 
      01-08-2010
On 1/8/2010 3:31 PM, Ian Collins wrote:
> Then the as-if rule outlined below would not apply. I think this is a
> circular argument!
>
>> 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.


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.
--
frank
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments