trap representation

Discussion in 'C Programming' started by Mantorok Redgormor, Sep 11, 2003.

  1. What does a trap representation mean in the standard?
    And how can ~0 cause a trap representation? Could someone point out
    the relevant sections in the standard?
     
    Mantorok Redgormor, Sep 11, 2003
    #1
    1. Advertising

  2. Mantorok Redgormor

    Malcolm Guest

    "Mantorok Redgormor" <> wrote in message
    > What does a trap representation mean in the standard?
    > And how can ~0 cause a trap representation? Could someone point
    > out the relevant sections in the standard?
    >

    A trap representaion is an illegal value for a variable to hold. The
    platform detects such values, and then terminates the program with an error
    message. For instance, a communist OS may decide that ascii dollar ($) is
    illegal in strings. When you try to assign '$' to a char, it could terminate
    with the error message "capitalist pig program".

    All bits set is allowed as a trap value. Thus ~0 could potentially trap.
     
    Malcolm, Sep 11, 2003
    #2
    1. Advertising

  3. "Malcolm" <> wrote in message
    news:bjqdan$ejh$...
    >
    > "Mantorok Redgormor" <> wrote in message
    > > What does a trap representation mean in the standard?
    > > And how can ~0 cause a trap representation? Could someone point
    > > out the relevant sections in the standard?
    > >

    > A trap representaion is an illegal value for a variable to hold. The
    > platform detects such values, and then terminates the program with an

    error
    > message. For instance, a communist OS may decide that ascii dollar ($) is
    > illegal in strings. When you try to assign '$' to a char, it could

    terminate
    > with the error message "capitalist pig program".
    >
    > All bits set is allowed as a trap value. Thus ~0 could potentially trap.


    Well, that could only be true with padding bits, or using other than twos
    complement arithmetic.

    The WATFIV Fortran compiler detected the use of undefined variables by
    initializing all bytes to X'81' (0x81 in C) and then checking for that. It
    worked pretty well, except for CHARACTER variables, in that it was pretty
    unlikely to occur accidentally.

    I believe that there may have been ones complement machines that would trap
    on ~0, which is -0, but I wouldn't worry too much about them.

    There was a suggestion not so long ago to detect twos complement machines
    with:

    #if ~0==-1

    which would be compile time, and I have no idea what the preprocessor says
    about traps.

    #if ~1==-2

    would work just as well, though.

    -- glen
     
    Glen Herrmannsfeldt, Sep 11, 2003
    #3
  4. Mantorok Redgormor

    Ben Pfaff Guest

    "Glen Herrmannsfeldt" <> writes:

    > "Malcolm" <> wrote in message
    > news:bjqdan$ejh$...
    > >
    > > "Mantorok Redgormor" <> wrote in message
    > > > What does a trap representation mean in the standard?
    > > > And how can ~0 cause a trap representation? Could someone point
    > > > out the relevant sections in the standard?
    > > >

    > > A trap representaion is an illegal value for a variable to hold. The
    > > platform detects such values, and then terminates the program with an

    > error
    > > message. For instance, a communist OS may decide that ascii dollar ($) is
    > > illegal in strings. When you try to assign '$' to a char, it could

    > terminate
    > > with the error message "capitalist pig program".
    > >
    > > All bits set is allowed as a trap value. Thus ~0 could potentially trap.

    >
    > Well, that could only be true with padding bits, or using other than twos
    > complement arithmetic.


    C99 supports ones' complement and sign-magnitude as well as two's
    complement, so portable code can't assume that two's complement
    is in use.
    --
    "A lesson for us all: Even in trivia there are traps."
    --Eric Sosman
     
    Ben Pfaff, Sep 11, 2003
    #4
  5. Mantorok Redgormor

    Lew Pitcher Guest

    On Thu, 11 Sep 2003 19:08:19 +0100, "Malcolm" <>
    wrote:

    >
    >"Mantorok Redgormor" <> wrote in message
    >> What does a trap representation mean in the standard?
    >> And how can ~0 cause a trap representation? Could someone point
    >> out the relevant sections in the standard?
    >>

    >A trap representaion is an illegal value for a variable to hold.

    [snip]
    >All bits set is allowed as a trap value. Thus ~0 could potentially trap.


    More specifically, on a ones-complement machine, all bits set is a potential
    trap representation, as it represents the value you get when you evaluate
    negative zero {(-0)}.

    On a two's complement machine, -0 == all bits zero == 0
    On a one's complement machine, -0 == all bits one != 0
    On either machine ~0 == all bits one != 0

    But the C abstract machine doesn't recognize a difference between 0 and -0, thus
    making the one's complement expression a potential trap value ("cant happen").

    --
    Lew Pitcher
    IT Consultant, Enterprise Technology Solutions
    Toronto Dominion Bank Financial Group

    (Opinions expressed are my own, not my employers')
     
    Lew Pitcher, Sep 11, 2003
    #5
  6. Mantorok Redgormor

    Ben Pfaff Guest

    "j" <> writes:

    > Shouldn't that be sign-extended instead of one's complement? I don't think
    > one's complement is proper terminology.


    See C99 6.2.6.2:

    - the sign bit has the value -(2N - 1) (one's complement).

    --
    Bite me! said C.
     
    Ben Pfaff, Sep 11, 2003
    #6
  7. Lew Pitcher wrote:
    >
    > On Thu, 11 Sep 2003 19:08:19 +0100, "Malcolm" <>
    > wrote:
    >
    > >
    > >"Mantorok Redgormor" <> wrote in message
    > >> What does a trap representation mean in the standard?
    > >> And how can ~0 cause a trap representation? Could someone point
    > >> out the relevant sections in the standard?
    > >>

    > >A trap representaion is an illegal value for a variable to hold.

    > [snip]
    > >All bits set is allowed as a trap value. Thus ~0 could potentially trap.

    >
    > More specifically, on a ones-complement machine, all bits set is a potential
    > trap representation, as it represents the value you get when you evaluate
    > negative zero {(-0)}.
    >
    > On a two's complement machine, -0 == all bits zero == 0
    > On a one's complement machine, -0 == all bits one != 0
    > On either machine ~0 == all bits one != 0
    >
    > But the C abstract machine doesn't recognize a difference between 0 and -0, thus
    > making the one's complement expression a potential trap value ("cant happen").
    >
    > --
    > Lew Pitcher
    > IT Consultant, Enterprise Technology Solutions
    > Toronto Dominion Bank Financial Group
    >
    > (Opinions expressed are my own, not my employers')


    For integer types (signed or unsigned, short or long), would all ones be
    an illegal value? I can see it for floats/doubles, but for integers???

    On every platform I have encoutered with 16-bit shorts and 32-bit ints,
    USHRT_MAX is 65535, which is sixteen ones in binary, and MAX_INT (or
    MAX_INT) is 4294967295 which is 32 ones. For these cases, "all ones"
    must be a legal value.
    --
    Fred L. Kleinschmidt
    Boeing Associate Technical Fellow
    Technical Architect, Common User Interface Services
    M/S 2R-94 (206)544-5225
     
    Fred L. Kleinschmidt, Sep 11, 2003
    #7
  8. Mantorok Redgormor

    j Guest

    "Ben Pfaff" <> wrote in message
    news:...
    > "Glen Herrmannsfeldt" <> writes:
    >
    > > "Malcolm" <> wrote in message
    > > news:bjqdan$ejh$...
    > > >
    > > > "Mantorok Redgormor" <> wrote in message
    > > > > What does a trap representation mean in the standard?
    > > > > And how can ~0 cause a trap representation? Could someone point
    > > > > out the relevant sections in the standard?
    > > > >
    > > > A trap representaion is an illegal value for a variable to hold. The
    > > > platform detects such values, and then terminates the program with an

    > > error
    > > > message. For instance, a communist OS may decide that ascii dollar ($)

    is
    > > > illegal in strings. When you try to assign '$' to a char, it could

    > > terminate
    > > > with the error message "capitalist pig program".
    > > >
    > > > All bits set is allowed as a trap value. Thus ~0 could potentially

    trap.
    > >
    > > Well, that could only be true with padding bits, or using other than

    twos
    > > complement arithmetic.

    >
    > C99 supports ones' complement and sign-magnitude as well as two's
    > complement, so portable code can't assume that two's complement
    > is in use.
    > --
    > "A lesson for us all: Even in trivia there are traps."
    > --Eric Sosman


    Shouldn't that be sign-extended instead of one's complement? I don't think
    one's complement is proper terminology.
     
    j, Sep 11, 2003
    #8
  9. Mantorok Redgormor

    Malcolm Guest

    "Fred L. Kleinschmidt" <> wrote in
    >
    > For integer types (signed or unsigned, short or long), would all ones be
    > an illegal value? I can see it for floats/doubles, but for integers???
    >

    It's more a theoretical problem than anything you are likely to encounter. A
    machine doesn't have to use twos complement for negatives, and I believe it
    is permitted to disallow all bits set for unsigned types also, so INT_MAX
    might be 0xFFFE.
     
    Malcolm, Sep 11, 2003
    #9
  10. "Malcolm" <> writes:

    > "Mantorok Redgormor" <> wrote in message
    > > What does a trap representation mean in the standard?


    6.2.6.1#5: Certain object representations need not represent a value
    of the object type. If the stored value of an object has such a
    representation and is read by an lvalue expression that does not have
    character type, the behavior is undefined. If such a representation is
    produced by a side effect that modifies all or any part of the object by
    an lvalue expression that does not have character type, the behavior is
    undefined. Such a representation is called a trap representation.

    > > And how can ~0 cause a trap representation? Could someone point out
    > > the relevant sections in the standard?


    6.2.6.2#2: [...] Which of these [sign and magnitute, two's complement,
    one's complement] applies is implementation-defined, as is whether the
    value with sign bit 1 and all value bits zero (for the first two), or
    with sign bit and all value bits 1 (for one's complement), is a trap
    representation or a normal value. In the case of sign and magnitude and
    one's complement, if this representation is a normal value it is called a
    negative zero.

    > A trap representaion is an illegal value for a variable to hold. The
    > platform detects such values, and then terminates the program with an
    > error message.


    Actually, the implementation is not required to detect a trap
    representation. Using it causes undefined behavior.

    Martin
     
    Martin Dickopp, Sep 12, 2003
    #10
  11. Mantorok Redgormor

    pete Guest

    Malcolm wrote:

    > I believe it is permitted to disallow all bits set for
    > unsigned types also, so INT_MAX might be 0xFFFE.


    The minimum allowed value for INT_MAX is a little higher.
    Are you familiar with limits.h ?

    --
    pete
     
    pete, Sep 12, 2003
    #11
  12. Mantorok Redgormor

    pete Guest

    pete wrote:
    >
    > Malcolm wrote:
    >
    > > I believe it is permitted to disallow all bits set for
    > > unsigned types also, so INT_MAX might be 0xFFFE.

    >
    > The minimum allowed value for INT_MAX is a little higher.
    > Are you familiar with limits.h ?


    I meant UINT_MAX,
    and I think I completely misunderstood what you were saying.
    Sorry about that.

    --
    pete
     
    pete, Sep 12, 2003
    #12
  13. "Malcolm" <> wrote in message news:<bjqpg4$i14$>...
    ....
    > A machine doesn't have to use twos complement for negatives, and I believe it
    > is permitted to disallow all bits set for unsigned types also,


    Only if the unsigned type is padded. For unsigned integers, all value
    bits contribute and the order of the range of values is a power of
    two.

    > so INT_MAX might be 0xFFFE.


    This is also theoretically true, depending on your view of the
    standards, but not actually related to unsigned types. Note that
    UINT_MAX must be a value equal or greater than 65535 (0xFFFF).

    --
    Peter
     
    Peter Nilsson, Sep 12, 2003
    #13
  14. Mantorok Redgormor

    Lew Pitcher Guest

    Fred L. Kleinschmidt wrote:
    >
    > Lew Pitcher wrote:
    >
    >>On Thu, 11 Sep 2003 19:08:19 +0100, "Malcolm" <>
    >>wrote:
    >>
    >>
    >>>"Mantorok Redgormor" <> wrote in message
    >>>
    >>>>What does a trap representation mean in the standard?
    >>>>And how can ~0 cause a trap representation? Could someone point
    >>>>out the relevant sections in the standard?
    >>>>
    >>>
    >>>A trap representaion is an illegal value for a variable to hold.

    >>
    >>[snip]
    >>
    >>>All bits set is allowed as a trap value. Thus ~0 could potentially trap.

    >>
    >>More specifically, on a ones-complement machine, all bits set is a potential
    >>trap representation, as it represents the value you get when you evaluate
    >>negative zero {(-0)}.
    >>
    >>On a two's complement machine, -0 == all bits zero == 0
    >>On a one's complement machine, -0 == all bits one != 0
    >>On either machine ~0 == all bits one != 0
    >>
    >>But the C abstract machine doesn't recognize a difference between 0 and -0, thus
    >>making the one's complement expression a potential trap value ("cant happen").
    >>
    >>--
    >>Lew Pitcher
    >>IT Consultant, Enterprise Technology Solutions
    >>Toronto Dominion Bank Financial Group
    >>
    >>(Opinions expressed are my own, not my employers')

    >
    >
    > For integer types (signed or unsigned, short or long), would all ones be
    > an illegal value? I can see it for floats/doubles, but for integers???
    >
    > On every platform I have encoutered with 16-bit shorts and 32-bit ints,
    > USHRT_MAX is 65535, which is sixteen ones in binary, and MAX_INT (or
    > MAX_INT) is 4294967295 which is 32 ones. For these cases, "all ones"
    > must be a legal value.


    You've been working on twos-complement systems, I see.
    Ones-complement is different.

    On a twos-complement system
    -n = ~n + 1

    That is to say, if

    0 == 000
    1 == 001
    2 == 010
    3 == 011

    then

    -1 == (~ 001) + 1 == 110 + 1 == 111
    -2 == (~ 010) + 1 == 101 + 1 == 110
    -3 == (~ 011) + 1 == 100 + 1 == 101

    and

    -0 == (~ 000) + 1 == 111 + 1 == 000 (discarding the overflow)

    However, on a ones-complement system,
    -n = ~n

    That is to say, if
    0 == 000
    1 == 001
    2 == 010
    3 == 011

    then

    -1 == (~ 001) == 110
    -2 == (~ 010) == 101
    -3 == (~ 011) == 100

    and
    -0 == (~ 000) == 111

    But, mathematically, -0 == 0, so 111 must equal 000

    So, either 111 is an illegal value (representing a number that has no legal
    existance), and thus a "trap value", or the language must arrange to make -0
    equal to 0.

    --
    Lew Pitcher

    Master Codewright and JOAT-in-training
    Registered Linux User #112576 (http://counter.li.org/)
    Slackware - Because I know what I'm doing.
     
    Lew Pitcher, Sep 13, 2003
    #14
  15. Mantorok Redgormor

    Chris Torek Guest

    In article <6s4x6-4.ca>
    Lew Pitcher <> writes (in part):
    >However, on a ones-complement system,
    > -n = ~n

    [snippage; hence]
    > -0 == (~ 000) == 111
    >
    >But, mathematically, -0 == 0, so 111 must equal 000
    >
    >So, either 111 is an illegal value (representing a number that has no legal
    >existance), and thus a "trap value", or the language must arrange to make -0
    >equal to 0.


    Incidentally, this is not *necessarily* a purely theoretical
    discussion. The Univac 1100 series of computers (whose native OS
    was EXEC-8, at least as used in the University of Maryland) had
    9-bit "char", 18-bit "short", 36-bit "int", and used ones' complement
    arithmetic, in their C compiler(s). This was all before the first
    C standard came out in 1989, and I do not know if the C compiler(s)
    was/were ever made C89-conformant -- but the machines did exist
    and did have at least one C compiler.

    I never used these machine enough to learn precisely how they
    treated negative zero in integer operations. One might note,
    however, that machines with ones' complement or sign-and-magnitude
    integer arithmetic avoid a nasty problem that occurs in today's
    two's complement hardware:

    int x = INT_MIN;
    printf("x = %d\n", x); /* outputs -32768 or -2147483648, for instance */
    x = -x; /* what happens here? */
    printf("-x = %d\n", x); /* what gets printed? */

    If you try this on your machine (for the generic "you" reading
    this), you will probably see that -x is *still* negative, and
    x == -x. If your machine used one of the other two representations,
    -x would be positive.
    --
    In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://67.40.109.61/torek/index.html (for the moment)
    Reading email is like searching for food in the garbage, thanks to spammers.
     
    Chris Torek, Sep 13, 2003
    #15
  16. "Chris Torek" <> wrote in message
    news:bjvluh$o6r$...
    > In article <6s4x6-4.ca>
    > Lew Pitcher <> writes (in part):
    > >However, on a ones-complement system,
    > > -n = ~n

    > [snippage; hence]
    > > -0 == (~ 000) == 111
    > >
    > >But, mathematically, -0 == 0, so 111 must equal 000
    > >
    > >So, either 111 is an illegal value (representing a number that has no

    legal
    > >existance), and thus a "trap value", or the language must arrange to

    make -0
    > >equal to 0.

    >
    > Incidentally, this is not *necessarily* a purely theoretical
    > discussion. The Univac 1100 series of computers (whose native OS
    > was EXEC-8, at least as used in the University of Maryland) had
    > 9-bit "char", 18-bit "short", 36-bit "int", and used ones' complement
    > arithmetic, in their C compiler(s). This was all before the first
    > C standard came out in 1989, and I do not know if the C compiler(s)
    > was/were ever made C89-conformant -- but the machines did exist
    > and did have at least one C compiler.


    I have been told that Univac still builds and sells ones complement
    machines. I have no idea about C compilers for them, though. CDC machines
    are/were also ones complement. There are people working on emulators, I
    don't know how many real machines are still running.

    > I never used these machine enough to learn precisely how they
    > treated negative zero in integer operations. One might note,
    > however, that machines with ones' complement or sign-and-magnitude
    > integer arithmetic avoid a nasty problem that occurs in today's
    > two's complement hardware:
    >
    > int x = INT_MIN;
    > printf("x = %d\n", x); /* outputs -32768 or -2147483648, for instance

    */
    > x = -x; /* what happens here? */
    > printf("-x = %d\n", x); /* what gets printed? */
    >
    > If you try this on your machine (for the generic "you" reading
    > this), you will probably see that -x is *still* negative, and
    > x == -x. If your machine used one of the other two representations,
    > -x would be positive.


    Early in my Fortran programming years, B.C. (Before C was invented), I had
    a program to print out
    2**I in a loop, using 16 bit integers and noticed the -32768 followed by
    zeros. It didn't take long to figure out what happened, but it was
    surprising at first. Note that Fortran, unlike C, has integer
    exponentiation, both integer to integer power and real to integer power.

    I only recently learned that it is allowable for -INT_MAX-1 to be a trap
    representation for twos complement machines. That is one answer to the
    problem, though I think it only makes things worse.

    -- glen
     
    Glen Herrmannsfeldt, Sep 13, 2003
    #16
  17. Mantorok Redgormor

    LibraryUser Guest

    Chris Torek wrote:
    >

    .... snip ...
    >
    > I never used these machine enough to learn precisely how they
    > treated negative zero in integer operations. One might note,
    > however, that machines with ones' complement or sign-and-magnitude
    > integer arithmetic avoid a nasty problem that occurs in today's
    > two's complement hardware:
    >
    > int x = INT_MIN;
    > printf("x = %d\n", x); /* outputs -32768 or -2147483648, for instance */
    > x = -x; /* what happens here? */
    > printf("-x = %d\n", x); /* what gets printed? */
    >
    > If you try this on your machine (for the generic "you" reading
    > this), you will probably see that -x is *still* negative, and
    > x == -x. If your machine used one of the other two representations,
    > -x would be positive.


    There are definite advantages, in some cases, for the use of 1's
    complement arithmetic. By making the basic arithmetic operation
    a subtractor, one can prevent the occurence of -0, allowing it to
    be a trap representation. The advantages show up better in
    decimal machines using 9's complement, but not for C standards
    compliance.

    In your example, there is no reason why INT_MIN should not be odd
    on a 2's complement machine, AFAICT. This again allows INT_MIN-1
    to be a trap representation, but is much more awkward that the
    equivalent on a 1's comp. machine.

    --
    Replies should be to the newsgroup
    Chuck Falconer, on vacation.
     
    LibraryUser, Sep 14, 2003
    #17
  18. Mantorok Redgormor

    Eric Sosman Guest

    j wrote:
    >
    > Shouldn't that be sign-extended instead of one's complement? I don't think
    > one's complement is proper terminology.


    The Standard uses the term "one's complement" in section
    6.2.6.2, paragraph 2. That's authoritative on comp.lang.c.

    However, Donald Knuth writes "ones' complement" in "The
    Art of Computer Programming, Volume II: Seminumerical Algorithms,"
    section 4.1. In the 1999 edition of that book, he goes so far
    as to insert a short note explaining why "one's" is wrong and
    "ones'" is right, and why the opposite situation holds for
    "two's complement." For the world beyond comp.lang.c, Knuth
    is considered authoritative or at least encyclopedic.

    Summary: Two authorities disagree, and you'll have to choose
    between them for yourself. Or perhaps adopt an entirely different
    authority, like Lawrence Welk: "A-one-an'-a-two's complement."

    --
     
    Eric Sosman, Sep 18, 2003
    #18
  19. Mantorok Redgormor

    j Guest

    "Eric Sosman" <> wrote in message
    news:...
    > j wrote:
    > >
    > > Shouldn't that be sign-extended instead of one's complement? I don't

    think
    > > one's complement is proper terminology.

    >
    > The Standard uses the term "one's complement" in section
    > 6.2.6.2, paragraph 2. That's authoritative on comp.lang.c.
    >
    > However, Donald Knuth writes "ones' complement" in "The
    > Art of Computer Programming, Volume II: Seminumerical Algorithms,"
    > section 4.1. In the 1999 edition of that book, he goes so far
    > as to insert a short note explaining why "one's" is wrong and
    > "ones'" is right, and why the opposite situation holds for
    > "two's complement." For the world beyond comp.lang.c, Knuth
    > is considered authoritative or at least encyclopedic.
    >
    > Summary: Two authorities disagree, and you'll have to choose
    > between them for yourself. Or perhaps adopt an entirely different
    > authority, like Lawrence Welk: "A-one-an'-a-two's complement."
    >
    > --
    >


    I guess some people use it to just constrast with two's complement. I guess
    I'll use one's complement here to prevent any confusion since it is used in
    the standard. :)
     
    j, Sep 19, 2003
    #19
    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. pemo

    trap representation

    pemo, Dec 5, 2005, in forum: C Programming
    Replies:
    11
    Views:
    545
    Tim Rentsch
    Dec 14, 2005
  2. ramu

    Trap representation

    ramu, Jan 31, 2006, in forum: C Programming
    Replies:
    2
    Views:
    342
    CBFalconer
    Jan 31, 2006
  3. trap representation

    , Jan 12, 2007, in forum: C Programming
    Replies:
    6
    Views:
    1,644
  4. Richard Tobin

    Trap representation

    Richard Tobin, Jun 22, 2007, in forum: C Programming
    Replies:
    10
    Views:
    576
    Keith Thompson
    Jun 23, 2007
  5. Army1987
    Replies:
    6
    Views:
    346
    CBFalconer
    Jul 7, 2007
Loading...

Share This Page