all bits zero representation

all bits zero representation

Post by nethle » Wed, 21 Apr 2004 13:59:47

What's the story on this?
I see where the DRs are listed
that a proposed change was accepted.

Has it been included in a TC?
Because some committee members here
seem to advocate its use.

So should we follow the lead and
assume all implementations allow
all zero bits for integer types to
represent the value zero?

Or is it more correct to know that
this only works for unsigned char types
until it is stated otherwise in a TC?


all bits zero representation

Post by Antoine Le » Wed, 21 Apr 2004 16:54:44

En XXXX@XXXXX.COM , Mantorok Redgormor va

I believe it is what you are reading.

So it would.

No, because if it had, it would been said so.

Yes, because it will be included in some TC at some future point of time.

This depends of your needs. If you are an implementor, it is the wrong way
to implement trapping all-0 representation. If you are a programmer dealing
with some current compiler, or in fact if you have to deal with any compiler
that may have such representation, you cannot assume all-0 will not trap.



all bits zero representation

Post by Jack Klei » Thu, 22 Apr 2004 12:57:36

On 19 Apr 2004 21:59:47 -0700, XXXX@XXXXX.COM (Mantorok Redgormor)
wrote in comp.std.c:

Note that even without the TC being added to the standard as yet, all
bits zero must represent a valid value of 0 in all the character
types, as for any signed integer type the representation for all
non-negative values must be the same as the corresponding unsigned

Also note that all bits zero must produce a valid value of 0 in all of
the exact width intx_t and unitx_t that a compiler must provide if it
has the appropriate underlying types.

Jack Klein
FAQs for
comp.lang.c ~scs/C-faq/top.html
comp.lang.c++ ++-faq-lite/
alt.comp.lang.learn.c-c++ ~ajo/docs/FAQ-acllc.html

all bits zero representation

Post by NOSPAMdav » Fri, 23 Apr 2004 08:47:34

According to Mantorok Redgormor < XXXX@XXXXX.COM >:

Regardless of the legal technicalities, any compiler vendor
who has any concern about supporting legacy C89 code would
already have to avoid making all-bits-zero a trap representation
for integers. Otherwise, they would break a ton of C89 code
that properly used calloc for integer arrays. So I suspect
that this DR is simply making official what everyone was already
doing in practice anyway. The only exception might be some
little C compiler for a new embedded system where they
don't expect any customer demand for supporting old code - and
now, even such a vendor knows better than to make this a
trap representation in the future. So I suspect the practical
answer is "go ahead and assume that, and don't worry about waiting
for the TC unless you are specifically writing for
a system you know has such a problem in the near future."

I welcome correction from anyone who knows of any existing compilers
that have a problem.

Dave Wallace (Remove NOSPAM from my address to email me)
It is quite humbling to realize that the storage occupied by the longest
line from a typical Usenet posting is sufficient to provide a state space
so vast that all the computation power in the world can not conquer it.

all bits zero representation

Post by kuype » Fri, 23 Apr 2004 23:32:48


I realize that calloc()ing arrays of just about any type is in fact
safe on most implementations that have ever seen actual use. However,
was it in fact guaranteed under the C89 standard that calloc()ing an
array of integers was safe? I realize that the wording about trap
representations is new with C99; however, I was under the impression
that the committee's position is that this wording clarifies something
that was already true in C89, that it doesn't count as an actual
change. I don't have a copy of the C89 standard, so I can't be sure.

all bits zero representation

Post by Dan.Po » Sat, 24 Apr 2004 01:03:08

In < XXXX@XXXXX.COM > XXXX@XXXXX.COM (James Kuyper) writes:

You have to do a lot of "imaginative" reading of the C89 wording to see
the padding bits and especially the trap representations. What I can
find relevant in my 1988 draft is:

For each of the signed integer types, there is a corresponding (but
different) unsigned integer type (designated with the keyword unsigned)
that uses the same amount of storage (including sign information)
and has the same alignment requirements. The range of nonnegative
values of a signed integer type is a subrange of the corresponding
unsigned integer type, and the representation of the same value in
each type is the same.
The type char, the signed and unsigned integer types, and the
enumerated types are collectively called integral types. The
representations of integral types shall define values by use of a
pure binary numeration system. [*] The representations of floating
types are unspecified.


[*] A positional representation for integers that uses the binary
digits 0 and 1, in which the values represented by successive bits
are additive, begin with 1, and are multiplied by successive integral
powers of 2, except perhaps the bit with the highest position.

The only hint of trap representations is implicitly contained in:

If an object that has automatic storage duration is not initialized
explicitly, its value is indeterminate.

combined with the definition of undefined behaviour that includes the
use of indeterminately-valued objects. There is no explicit wording
rendering the type unsigned char special and exempt from the above quote.

Then again, things may be different in the final version of C89...

Dan Pop
DESY Zeuthen, RZ group