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

[Army1987]

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")

[Harald van =?UTF-8?B?RMSzaw==?=]

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>

[Dave Vandervies]

In article <pa****************************@NOSPAM.it>,
Army1987 <ar******@NOSPAM.itwrote:

>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 dj******@csclub.uwaterloo.ca

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

[Keith Thompson]

Army1987 <ar******@NOSPAM.itwrites:

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) ks***@mib.org <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"

[CBFalconer]

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

[Army1987]

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

[CBFalconer]

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