The "as-if rule"

Discussion in 'C Programming' started by Stefan Ram, Jan 8, 2010.

  1. Stefan Ram

    Stefan Ram Guest

    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 Ram, Jan 8, 2010
    #1
    1. Advertising

  2. -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.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jan 8, 2010
    #2
    1. Advertising

  3. Stefan Ram

    Walter Banks Guest

    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
     
    Walter Banks, Jan 8, 2010
    #3
  4. Walter Banks <> 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) <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"
     
    Keith Thompson, Jan 8, 2010
    #4
  5. Stefan Ram

    Ian Collins Guest

    Keith Thompson wrote:
    > Walter Banks <> 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
     
    Ian Collins, Jan 8, 2010
    #5
  6. Ian Collins <> writes:
    > Keith Thompson wrote:
    >> Walter Banks <> 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) <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"
     
    Keith Thompson, Jan 8, 2010
    #6
  7. Stefan Ram

    Ian Collins Guest

    Keith Thompson wrote:
    > Ian Collins <> writes:
    >> Keith Thompson wrote:
    >>> Walter Banks <> 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
     
    Ian Collins, Jan 8, 2010
    #7
  8. Stefan Ram

    Frank Guest

    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
     
    Frank, Jan 8, 2010
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jurjen de Groot

    Re: Business rule implementation

    Jurjen de Groot, Aug 6, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    360
    Jurjen de Groot
    Aug 6, 2003
  2. Daniel
    Replies:
    1
    Views:
    1,753
    Steven Cheng[MSFT]
    Jul 10, 2004
  3. Miguel Dias Moura

    How to display records according to this rule?

    Miguel Dias Moura, Dec 7, 2004, in forum: ASP .Net
    Replies:
    5
    Views:
    365
    Martin Dechev
    Dec 9, 2004
  4. yer darn tootin
    Replies:
    3
    Views:
    2,727
    yer darn tootin
    Mar 6, 2005
  5. Replies:
    0
    Views:
    1,391
Loading...

Share This Page