Can "all bits zero" be a trap representation for integral types?

Discussion in 'C Programming' started by Army1987, Jul 6, 2007.

  1. Army1987

    Army1987 Guest

    Reliable sources (whose names I'm not allowed to disclose) told me that on
    the next version of the Deathstation (version 10000, or DS10K) an integral
    type (they didn't tell which) will have a odd parity bit, that is a bit
    which is set if an even number of value/sign bits are set, and unset
    otherwise. If the parity is wrong, the representation is a trap, and they
    didn't tell me how it is handled (and they won't even have to tell this
    when they release the DS10K, as it is UB). Of course, "all bits zero" will
    be a trap representation, so I won't be able to port there code which
    assumes that memory allocated with calloc(size) or erased with
    memset(array, 0, size) can be used as an array of integers which has been
    initialized to {0}. Will they still be allowed to claim that their
    platform conforms to the ISO standard? Footnote 44 in 6.2.6.2 makes me
    fear they will.

    --
    Army1987
    (Replace "NOSPAM" with "email")
     
    Army1987, Jul 6, 2007
    #1
    1. Advertising

  2. In article <>,
    Army1987 <> wrote:
    >Reliable sources (whose names I'm not allowed to disclose) told me that on
    >the next version of the Deathstation (version 10000, or DS10K) an integral
    >type (they didn't tell which) will have a odd parity bit, that is a bit
    >which is set if an even number of value/sign bits are set, and unset
    >otherwise. If the parity is wrong, the representation is a trap, and they
    >didn't tell me how it is handled (and they won't even have to tell this
    >when they release the DS10K, as it is UB). Of course, "all bits zero" will
    >be a trap representation, so I won't be able to port there code which
    >assumes that memory allocated with calloc(size) or erased with
    >memset(array, 0, size) can be used as an array of integers which has been
    >initialized to {0}. Will they still be allowed to claim that their
    >platform conforms to the ISO standard? Footnote 44 in 6.2.6.2 makes me
    >fear they will.


    I believe that as long as the integral type they're talking about isn't
    unsigned char, they will.


    dave
    (others will be sure to correct me if I'm wrong.)

    --
    Dave Vandervies
    > Actually, anything false posted here tends to get corrected pretty quickly.

    Actually, anything posted here tends to get corrected pretty quickly.
    --Ben Pfaff and Joe Wright in comp.lang.c
     
    Dave Vandervies, Jul 6, 2007
    #2
    1. Advertising

  3. Army1987 wrote:
    > Reliable sources (whose names I'm not allowed to disclose) told me that on
    > the next version of the Deathstation (version 10000, or DS10K) an integral
    > type (they didn't tell which) will have a odd parity bit, that is a bit
    > which is set if an even number of value/sign bits are set, and unset
    > otherwise. If the parity is wrong, the representation is a trap, and they
    > didn't tell me how it is handled (and they won't even have to tell this
    > when they release the DS10K, as it is UB). Of course, "all bits zero" will
    > be a trap representation, so I won't be able to port there code which
    > assumes that memory allocated with calloc(size) or erased with
    > memset(array, 0, size) can be used as an array of integers which has been
    > initialized to {0}. Will they still be allowed to claim that their
    > platform conforms to the ISO standard? Footnote 44 in 6.2.6.2 makes me
    > fear they will.


    The current ISO standard is C99+TC1+TC2, and TC2 added a requirement that
    all bits zero be a valid representation for zero for all integer types. See
    DR #263 <http://open-std.org/jtc1/sc22/wg14/www/docs/dr_263.htm>
     
    Harald van =?UTF-8?B?RMSzaw==?=, Jul 6, 2007
    #3
  4. Army1987 <> writes:
    > Reliable sources (whose names I'm not allowed to disclose) told me that on
    > the next version of the Deathstation (version 10000, or DS10K) an integral
    > type (they didn't tell which) will have a odd parity bit, that is a bit
    > which is set if an even number of value/sign bits are set, and unset
    > otherwise. If the parity is wrong, the representation is a trap, and they
    > didn't tell me how it is handled (and they won't even have to tell this
    > when they release the DS10K, as it is UB). Of course, "all bits zero" will
    > be a trap representation, so I won't be able to port there code which
    > assumes that memory allocated with calloc(size) or erased with
    > memset(array, 0, size) can be used as an array of integers which has been
    > initialized to {0}. Will they still be allowed to claim that their
    > platform conforms to the ISO standard? Footnote 44 in 6.2.6.2 makes me
    > fear they will.


    n1124 6.2.6.2p5 says;

    For any integer type, the object representation where all the bits
    are zero shall be a representation of the value zero in that type.

    This wording does not appear in the original C99 standard; it was
    added by TC2, in response to Defect Report # 263,
    <http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_263.htm>.

    Whether the DS9K or DS10K's C compiler conforms to n1124 or merely to
    C99 is another question.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jul 6, 2007
    #4
  5. Army1987

    CBFalconer Guest

    Harald van D?k wrote:
    >

    .... snip ...
    >
    > The current ISO standard is C99+TC1+TC2, and TC2 added a
    > requirement that all bits zero be a valid representation for zero
    > for all integer types. See DR #263
    > <http://open-std.org/jtc1/sc22/wg14/www/docs/dr_263.htm>


    As I understand it that was added only after research showed that
    no existing compiler systems would be affected by the added
    requirement.

    --
    <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
    <http://www.securityfocus.com/columnists/423>
    <http://www.aaxnet.com/editor/edit043.html>
    cbfalconer at maineline dot net



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Jul 6, 2007
    #5
  6. Army1987

    Army1987 Guest

    On Fri, 06 Jul 2007 16:59:45 -0400, CBFalconer wrote:

    > Harald van D?k wrote:
    >>

    > ... snip ...
    >>
    >> The current ISO standard is C99+TC1+TC2, and TC2 added a
    >> requirement that all bits zero be a valid representation for zero
    >> for all integer types. See DR #263
    >> <http://open-std.org/jtc1/sc22/wg14/www/docs/dr_263.htm>

    >
    > As I understand it that was added only after research showed that
    > no existing compiler systems would be affected by the added
    > requirement.


    I had already read in the Rationale that the Committee did not
    know of any machines with user-accessible parity bits within an
    integer. But I also read that padding bits were added in C99. I
    can't see why they didn't just disallow that thing, by simplily
    requiring padding bits to be ignored. (Did any member of the
    Committee work for ART, the makers of the DS9K?)
     
    Army1987, Jul 7, 2007
    #6
  7. Army1987

    CBFalconer Guest

    Army1987 wrote:
    > CBFalconer wrote:
    >> Harald van D?k wrote:
    >>>

    >> ... snip ...
    >>>
    >>> The current ISO standard is C99+TC1+TC2, and TC2 added a
    >>> requirement that all bits zero be a valid representation for zero
    >>> for all integer types. See DR #263
    >>> <http://open-std.org/jtc1/sc22/wg14/www/docs/dr_263.htm>

    >>
    >> As I understand it that was added only after research showed that
    >> no existing compiler systems would be affected by the added
    >> requirement.

    >
    > I had already read in the Rationale that the Committee did not
    > know of any machines with user-accessible parity bits within an
    > integer. But I also read that padding bits were added in C99. I
    > can't see why they didn't just disallow that thing, by simplily
    > requiring padding bits to be ignored. (Did any member of the
    > Committee work for ART, the makers of the DS9K?)


    Padding has been around since 1 BC, and has always been ignored.
    Such bits are intended to detect use of uninitialized, or
    erroneous, values. Some can be seen by an unsigned char access.

    --
    <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
    <http://www.securityfocus.com/columnists/423>
    <http://www.aaxnet.com/editor/edit043.html>
    cbfalconer at maineline dot net



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Jul 7, 2007
    #7
    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. Mantorok Redgormor

    trap representation

    Mantorok Redgormor, Sep 11, 2003, in forum: C Programming
    Replies:
    18
    Views:
    717
  2. joshc
    Replies:
    7
    Views:
    395
    DHOLLINGSWORTH2
    Feb 26, 2005
  3. pemo

    trap representation

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

    Trap representation

    ramu, Jan 31, 2006, in forum: C Programming
    Replies:
    2
    Views:
    342
    CBFalconer
    Jan 31, 2006
  5. Ersek, Laszlo

    all-bits-zero pointer-to-object representation

    Ersek, Laszlo, Apr 26, 2010, in forum: C Programming
    Replies:
    20
    Views:
    854
    Vincent Lefevre
    Apr 30, 2010
Loading...

Share This Page