[comp.std.c] all bits zero?

wittig@gmdzi.UUCP (Georg Wittig) (03/20/90)

Does ANSI C require that in the internal representation of the integer constant
``0'' all bits are zero?

What about ``0x0'' (hex.) or ``0000'' (oct.)?

If it IS allowed that in the internal representation not all bits are zero, is
it then possible to write a #if expression that tests if all bits of the integer
constant ``0'' are zero?
-- 
Georg Wittig   GMD-Z1.BI   P.O. Box 1240   D-5205 St. Augustin 1 (West Germany)
email: wittig@gmdzi.uucp   phone: (+49 2241) 14-2294
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"Freedom's just another word for nothing left to lose" (Kris Kristofferson)

henry@utzoo.uucp (Henry Spencer) (03/22/90)

In article <2108@gmdzi.UUCP> wittig@gmdzi.UUCP (Georg Wittig) writes:
>Does ANSI C require that in the internal representation of the integer constant
>``0'' all bits are zero?

For integers, ANSI C essentially demands this.
-- 
Never recompute what you      |     Henry Spencer at U of Toronto Zoology
can precompute.               | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

karl@haddock.ima.isc.com (Karl Heuer) (03/22/90)

In article <2108@gmdzi.UUCP> wittig@gmdzi.UUCP (Georg Wittig) writes:
>Does ANSI C require that in the internal representation of the integer
>constant ``0'' all bits are zero?

Assuming it's not in a pointer context--in which case it would have been a
null pointer constant, not an integer constant, despite having the same
spelling--yes.  Non-negative integers, signed or unsigned, whether formed by
constants of any radix or by run-time expressions, are required to be
represented in a "pure binary system".  Without such a guarantee, the bitwise
operators would be much less useful.

Much less is said about negative integers.  The value -1 looks like 1111 in
two's complement, 1110 in one's complement, and 1001 in sign-magnitude.  All
of these (and presumably even stranger things) are legal; in the latter two
cases a conversion from signed int to unsigned int actually entails a change
in the bit-pattern (since (unsigned)-1 == UINT_MAX which looks like 1111).

Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint

gwyn@smoke.BRL.MIL (Doug Gwyn) (03/22/90)

In article <2108@gmdzi.UUCP> wittig@gmdzi.UUCP (Georg Wittig) writes:
>Does ANSI C require that in the internal representation of the integer constant
>``0'' all bits are zero?

A "pure binary numeration system" is required for the representation of
integral types (that term is defined in the American National Dictionary
for Information Processing Systems), so that, other than possibly the
sign bit, all bits used to represent the value 0 must be 0.

>What about ``0x0'' (hex.) or ``0000'' (oct.)?

0x0==0 && 0000==0

They're not distinct types, just different ways of writing the value 0
in source code.

>If it IS allowed that in the internal representation not all bits are
>zero, is it then possible to write a #if expression that tests if all
>bits of the integer constant ``0'' are zero?

No, because the preprocessor is not required to use the same
representation as in the run-time environment.

scjones@sdrc.UUCP (Larry Jones) (03/22/90)

In article <2108@gmdzi.UUCP>, wittig@gmdzi.UUCP (Georg Wittig) writes:
> Does ANSI C require that in the internal representation of the integer constant
> ``0'' all bits are zero?

ANSI C requires a pure binary numeration system for all integral
types, so "yes".
----
Larry Jones                         UUCP: uunet!sdrc!scjones
SDRC                                      scjones@SDRC.UU.NET
2000 Eastman Dr.                    BIX:  ltl
Milford, OH  45150-2789             AT&T: (513) 576-2070
"You know how Einstein got bad grades as a kid?  Well MINE are even WORSE!"
-Calvin

jc@atcmp.nl (Jan Christiaan van Winkel) (03/22/90)

From article <16237@haddock.ima.isc.com>, by karl@haddock.ima.isc.com (Karl Heuer):
> In article <2108@gmdzi.UUCP> wittig@gmdzi.UUCP (Georg Wittig) writes:
>>Does ANSI C require that in the internal representation of the integer
>>constant ``0'' all bits are zero?
> 
> Assuming it's not in a pointer context--in which case it would have been a
> null pointer constant, not an integer constant, despite having the same
> spelling--yes.  Non-negative integers, signed or unsigned, whether formed by

And how about floats/double-s? I know the IEEE standard says that an exponent
of all zeroes signifies the number 0.0, but how about other float notations?

bdm659@csc.anu.oz (03/23/90)

In article <1217@sdrc.UUCP>, scjones@sdrc.UUCP (Larry Jones) writes:
> In article <2108@gmdzi.UUCP>, wittig@gmdzi.UUCP (Georg Wittig) writes:
>> Does ANSI C require that in the internal representation of the integer constant
>> ``0'' all bits are zero?
>
> ANSI C requires a pure binary numeration system for all integral
> types, so "yes".
[... and similar answers from lots of other people]

I think you are all wrong.  The implementation must only behave *as if*
integral types are represented in binary.  Integers might in fact be
stored in packed-decimal or something; if conforming programs can't
tell the difference, it doesn't matter.  Such an implementation is
going to have to work hard to do bitwise operations, for example, but
that's not the issue.

I think the correct answer to the original question is:  "Zero can be
stored any way the compiler-writer felt like it.  However, you won't
be able to write an ANSI-conforming program which can tell that it isn't
stored in binary with all bits zero."

Brendan McKay.   bdm@anucsd.oz.au  or  bdm659@csc1.anu.oz.au

henry@utzoo.uucp (Henry Spencer) (03/23/90)

In article <568@atcmpe.atcmp.nl> jc@atcmp.nl (Jan Christiaan van Winkel) writes:
>And how about floats/double-s? I know the IEEE standard says that an exponent
>of all zeroes signifies the number 0.0, but how about other float notations?

No promises are made about floating-point representations.  Only the integers
are constrained to be represented in a known form, partly because the bit
operators don't make much sense otherwise.
-- 
US space station:  8 years    |     Henry Spencer at U of Toronto Zoology
and still no hardware built.  | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

jimp@cognos.UUCP (Jim Patterson) (04/03/90)

In article <12570051@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes:
>>   how many machines exist where the following does not hold.
>> 
>>    char*, struct FOO* NULL is represented as binary zeros
>
>I know of at least one (albeit only by software convention): on the classic
>HP3000's (16-bit stack machines), a pointer with all-zeros is a perfectly
>valid address

On the "classic" HP 3000 though, there is no "invalid" address. Using
0 for NULL is as good as any choice; all that the compiler-system has
to do to ensure that this is legal is reserve the first word of the
address space (i.e.  make sure that no "valid" object ever goes
there). Putting a string literal "(nil)" there might be nice (it causes
printf() to do nice things with NULL pointers, like the old PDP-11
compilers, apparently).

Note that the ANSI definition of a null pointer constant states simply
that it cannot point to any valid object. So long as the compiler
never allocates data at that address (either static or auto), and so
long as the memory allocation subsystem malloc et. al. don't (except
perhaps for size 0 objects), then this constraint is satisfied.
In fact, the compiler need not actually prevent dereferencing of "null";
the behaviour is undefined according to the standard.

>I must admit, however, that the C compiler on that machine (at least, the
>one that I am familiar with - the CCS C/3000 compiler) leaves NULL as
>"all-zeroes",

No doubt a wise choice given the immense amount of "prior art" regarding
NULL and 0.


-- 
Jim Patterson                              Cognos Incorporated
UUCP:decvax!utzoo!dciem!nrcaer!cognos!jimp P.O. BOX 9707    
PHONE:(613)738-1440                        3755 Riverside Drive
                                           Ottawa, Ont  K1G 3Z4