Many Happy Returns

[Richard Heathfield]

#include <stdio.h>

int main(void)
{
printf("Happy Birthday, Dennis Ritchie. %d today.\n", ~0&0x1f<<1);
return 0;
}

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Martin Dickopp]

Richard Heathfield <do******@address.co.uk.invalid> writes:

#include <stdio.h>

int main(void)
{
printf("Happy Birthday, Dennis Ritchie. %d today.\n", ~0&0x1f<<1);
return 0;
}

Doesn't this program cause undefined behavior?

Martin

[pete]

Martin Dickopp wrote:

Richard Heathfield <do******@address.co.uk.invalid> writes:

#include <stdio.h>

int main(void)
{
printf("Happy Birthday, Dennis Ritchie. %d today.\n", ~0&0x1f<<1);
return 0;
}

Doesn't this program cause undefined behavior?

#include <stdio.h>

int main(void)
{
printf("Happy Birthday, Dennis Ritchie. %u today.\n", ~0u&0x1f<<1);
return 0;
}

--
pete

[Mantorok Redgormor]

Richard Heathfield <do******@address.co.uk.invalid> wrote in message news:<bj**********@titan.btinternet.com>...

#include <stdio.h>

int main(void)
{
printf("Happy Birthday, Dennis Ritchie. %d today.\n", ~0&0x1f<<1);
return 0;
}

I can see why ~0 would be -1 since ~ inverts all bits, so your signed
bit ends up representing a negative and your value bits represent 1.
But why does 0x1f equal to some -1.994942 number? I was thinking 0x1f
would be equal to 1.000000 for %f and for %d just 1, but it doesn't.
Why is this?

[pete]

Mantorok Redgormor wrote:

Richard Heathfield <do******@address.co.uk.invalid> wrote in message news:<bj**********@titan.btinternet.com>...

#include <stdio.h>

int main(void)
{
printf("Happy Birthday, Dennis Ritchie. %d today.\n", ~0&0x1f<<1);
return 0;
}

I can see why ~0 would be -1 since ~ inverts all bits, so your signed
bit ends up representing a negative and your value bits represent 1.
But why does 0x1f equal to some -1.994942 number? I was thinking 0x1f
would be equal to 1.000000 for %f and for %d just 1, but it doesn't.
Why is this?

0x1f is 31
0x1f << 1 is 62

--
pete

[Richard Heathfield]

Martin Dickopp wrote:

Richard Heathfield <do******@address.co.uk.invalid> writes:

#include <stdio.h>

int main(void)
{
printf("Happy Birthday, Dennis Ritchie. %d today.\n", ~0&0x1f<<1);
return 0;
}

Doesn't this program cause undefined behavior?

What took you so long? :-)

A birthday wouldn't be the same without a tiny flame atop each candle.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Mantorok Redgormor]

pete <pf*****@mindspring.com> wrote in message news:<3F***********@mindspring.com>...

Mantorok Redgormor wrote:

Richard Heathfield <do******@address.co.uk.invalid> wrote in message news:<bj**********@titan.btinternet.com>...

#include <stdio.h>

int main(void)
{
printf("Happy Birthday, Dennis Ritchie. %d today.\n", ~0&0x1f<<1);
return 0;
}

I can see why ~0 would be -1 since ~ inverts all bits, so your signed
bit ends up representing a negative and your value bits represent 1.
But why does 0x1f equal to some -1.994942 number? I was thinking 0x1f
would be equal to 1.000000 for %f and for %d just 1, but it doesn't.
Why is this?

0x1f is 31
0x1f << 1 is 62

Duh. I was looking at 0x1f as the 'f' being a suffix. In the case of
representing numbers in base16, do these suffixes apply? Or are they
only applied to base10 numbers?

And ~0 what does the underlying representation look like for that?
I'm looking at it as

before:
00000000 00000000 00000000 00000000
^- sign bit - rest are value bits?

after:
11111111 11111111 11111111 11111111
^- sign bit now on, and so are all value bits?

Now all the bits have been inverted how do you get -1 from ~0?

[Joona I Palaste]

Mantorok Redgormor <ne*****@tokyo.com> scribbled the following:

pete <pf*****@mindspring.com> wrote in message news:<3F***********@mindspring.com>...

Mantorok Redgormor wrote:

> Richard Heathfield <do******@address.co.uk.invalid> wrote in message news:<bj**********@titan.btinternet.com>...
> > #include <stdio.h>
> >
> > int main(void)
> > {
> > printf("Happy Birthday, Dennis Ritchie. %d today.\n", ~0&0x1f<<1);
> > return 0;
> > }
>
> I can see why ~0 would be -1 since ~ inverts all bits, so your signed
> bit ends up representing a negative and your value bits represent 1.
> But why does 0x1f equal to some -1.994942 number? I was thinking 0x1f
> would be equal to 1.000000 for %f and for %d just 1, but it doesn't.
> Why is this?
0x1f is 31
0x1f << 1 is 62

Duh. I was looking at 0x1f as the 'f' being a suffix. In the case of
representing numbers in base16, do these suffixes apply? Or are they
only applied to base10 numbers?
They only apply to base10 (ten) numbers. Not mathematically elegant,
but easier to implement.
And ~0 what does the underlying representation look like for that?
I'm looking at it as before:
00000000 00000000 00000000 00000000
^- sign bit - rest are value bits? after:
11111111 11111111 11111111 11111111
^- sign bit now on, and so are all value bits? Now all the bits have been inverted how do you get -1 from ~0?

Two's complement arithmetic.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"I said 'play as you've never played before', not 'play as IF you've never
played before'!"
- Andy Capp

[pete]

Joona I Palaste wrote:

Duh. I was looking at 0x1f as the 'f' being a suffix. In the case of
representing numbers in base16, do these suffixes apply? Or are they
only applied to base10 numbers?

The suffixes which make sense, can be applied:

printf("%lu\n", 0x1flu);
printf("%lx\n", 0x1flu);

but 0x1f is a positive integer value,
you're not going to put "float" suffix on that.


They only apply to base10 (ten) numbers. Not mathematically elegant,
but easier to implement.

And ~0 what does the underlying representation look like for that?
I'm looking at it as

before:
00000000 00000000 00000000 00000000
^- sign bit - rest are value bits?

after:
11111111 11111111 11111111 11111111
^- sign bit now on, and so are all value bits?

Now all the bits have been inverted how do you get -1 from ~0?

Two's complement arithmetic.

--
pete

[Pieter Droogendijk]

On 9 Sep 2003 23:58:29 -0700
ne*****@tokyo.com (Mantorok Redgormor) wrote:

pete <pf*****@mindspring.com> wrote in message
news:<3F***********@mindspring.com>...

Mantorok Redgormor wrote:

Richard Heathfield <do******@address.co.uk.invalid> wrote in message
news:<bj**********@titan.btinternet.com>...
> #include <stdio.h>
>
> int main(void)
> {
> printf("Happy Birthday, Dennis Ritchie. %d today.\n", ~0&0x1f<<1);
> return 0;
> }

I can see why ~0 would be -1 since ~ inverts all bits, so your signed
bit ends up representing a negative and your value bits represent 1.
But why does 0x1f equal to some -1.994942 number? I was thinking 0x1f
would be equal to 1.000000 for %f and for %d just 1, but it doesn't.
Why is this?

0x1f is 31
0x1f << 1 is 62

Duh. I was looking at 0x1f as the 'f' being a suffix. In the case of
representing numbers in base16, do these suffixes apply? Or are they
only applied to base10 numbers?

And ~0 what does the underlying representation look like for that?
I'm looking at it as

before:
00000000 00000000 00000000 00000000
^- sign bit - rest are value bits?

after:
11111111 11111111 11111111 11111111
^- sign bit now on, and so are all value bits?

Now all the bits have been inverted how do you get -1 from ~0?

You're thinking of one's complement. In fact what's used is two's complement:

-x = 0-x = ~x+1

if x=0, 0-0 = 0 = ~0+1

so if ~0+1 = 0, ~0 must be -1.

exercise for you: what's 4-~-4? And 8-~-~-8?

--
char*x(c,k,s)char*k,*s;{if(!k)return*s-36?x(0,0,s+1):s;if(s)if(*s)c=10+(c?(x(
c,k,0),x(c,k+=*s-c,s+1),*k):(x(*s,k,s+1),0));else c=10;printf(&x(~0,0,k)[c-~-
c+"1"[~c<-c]],c);}main(){x(0,"^[kXc6]dn_eaoh$%c","-34*1'.+(,03#;+,)/'///*");}

[Martin Dickopp]

Richard Heathfield <do******@address.co.uk.invalid> writes:

Martin Dickopp wrote:

Richard Heathfield <do******@address.co.uk.invalid> writes:

#include <stdio.h>

int main(void)
{
printf("Happy Birthday, Dennis Ritchie. %d today.\n", ~0&0x1f<<1);
return 0;
}

Doesn't this program cause undefined behavior?

What took you so long? :-)

A birthday wouldn't be the same without a tiny flame atop each candle.

c.l.c is not a good place to look for flames. Most people here are too
nice for that. Try a "religious war" newsgroup - anything with the term
"advocacy" is probably a good starting point. :-)

Martin

[Dan Pop]

In <bj*************@news.t-online.com> Martin Dickopp <ex*************@zero-based.org> writes:

Richard Heathfield <do******@address.co.uk.invalid> writes:

#include <stdio.h>

int main(void)
{
printf("Happy Birthday, Dennis Ritchie. %d today.\n", ~0&0x1f<<1);
return 0;
}

Doesn't this program cause undefined behavior?

On a one's complement implementation, it's either undefined behaviour or
claiming that someone called Dennis Ritchie has just been born :-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Joe Wright]

Dan Pop wrote:

In <bj*************@news.t-online.com> Martin Dickopp <ex*************@zero-based.org> writes:

Richard Heathfield <do******@address.co.uk.invalid> writes:

#include <stdio.h>

int main(void)
{
printf("Happy Birthday, Dennis Ritchie. %d today.\n", ~0&0x1f<<1);
return 0;
}

Doesn't this program cause undefined behavior?

On a one's complement implementation, it's either undefined behaviour or
claiming that someone called Dennis Ritchie has just been born :-)

It does look curious but ~0& has no effect on 0x1f<<1 at all. A bit-wise
and of all ones yields the 'other' operand. I don't see that ones
complement has anything to do with it.
--
Joe Wright mailto:jo********@earthlink.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Ben Pfaff]

Joona I Palaste <pa*****@cc.helsinki.fi> writes:

Mantorok Redgormor <ne*****@tokyo.com> scribbled the following:

pete <pf*****@mindspring.com> wrote in message news:<3F***********@mindspring.com>...

0x1f is 31
0x1f << 1 is 62

Duh. I was looking at 0x1f as the 'f' being a suffix. In the case of
representing numbers in base16, do these suffixes apply? Or are they
only applied to base10 numbers?

They only apply to base10 (ten) numbers. Not mathematically elegant,
but easier to implement.

C99 has hexadecimal floating-point constants, but they are
required to have an exponent, so "0x1f" is not one.
--
"The lusers I know are so clueless, that if they were dipped in clue
musk and dropped in the middle of pack of horny clues, on clue prom
night during clue happy hour, they still couldn't get a clue."
--Michael Girdwood, in the monastery

[Martin Dickopp]

Da*****@cern.ch (Dan Pop) writes:

In <bj*************@news.t-online.com> Martin Dickopp <ex*************@zero-based.org> writes:

Richard Heathfield <do******@address.co.uk.invalid> writes:

#include <stdio.h>

int main(void)
{
printf("Happy Birthday, Dennis Ritchie. %d today.\n", ~0&0x1f<<1);
return 0;
}

Doesn't this program cause undefined behavior?

On a one's complement implementation, it's either undefined behaviour or
claiming that someone called Dennis Ritchie has just been born :-)

As far as I can see, it is implementation-defined whether or not `~0'
produces a trap representation on a one's complement implementation.
If it doesn't, it is unspecified if it produces a negative or normal
zero.

Before the `&' operator is evaluated, the result of `~0' is converted to
`unsigned int'. Is my understanding of 6.3.1.3 correct that a negative
zero becomes a zero when converted to `unsigned int'?

If I'm right so far, the expression `~0&0x1f<<1' either causes undefined
behavior (`~0' is a trap representation) or yields the value `0' on a
one's complement implementation.

But even in the latter case, the type of `~0&0x1f<<1' is `unsigned int',
so the fact that it corresponds to a "%d" format specifier causes
undefined behavior. An implementation is therefore free to write the
string "Someone called Dennis Ritchie has just been born.\n" to standard
output. ;)

Martin

[Lew Pitcher]

Martin Dickopp wrote:

Da*****@cern.ch (Dan Pop) writes:

In <bj*************@news.t-online.com> Martin Dickopp <ex*************@zero-based.org> writes:

Richard Heathfield <do******@address.co.uk.invalid> writes:
#include <stdio.h>

int main(void)
{
printf("Happy Birthday, Dennis Ritchie. %d today.\n", ~0&0x1f<<1);
return 0;
}

Doesn't this program cause undefined behavior?
On a one's complement implementation, it's either undefined behaviour or
claiming that someone called Dennis Ritchie has just been born :-)

As far as I can see, it is implementation-defined whether or not `~0'
produces a trap representation on a one's complement implementation.
If it doesn't, it is unspecified if it produces a negative or normal
zero.

Let me make sure that I follow your reasoning/concern here

On a ones-complement machine, A ones-complement negative zero may be a trap
representation. On such a machine, ~0 may also represent a trap value, as it
would be binary identical to an ones-complement negative zero.
Before the `&' operator is evaluated, the result of `~0' is converted to
`unsigned int'. Is my understanding of 6.3.1.3 correct that a negative
zero becomes a zero when converted to `unsigned int'?
Assuming that ~0 is not a trap representation on this ones-complement
machine, then the C code would have to convert the ones-complement negative
zero (which is indistinguishable from the intended ~0) to a positive zero
(which would be binary zero).
If I'm right so far, the expression `~0&0x1f<<1' either causes undefined
behavior (`~0' is a trap representation) or yields the value `0' on a
one's complement implementation.
Again assuming that ~0 isn't a trap value, then the arithmetical result of
anding a value with a zero (the result of the conversion of the
ones-complement negative zero to a usable positive zero) is zero.
But even in the latter case, the type of `~0&0x1f<<1' is `unsigned int',
so the fact that it corresponds to a "%d" format specifier causes
undefined behavior. An implementation is therefore free to write the
string "Someone called Dennis Ritchie has just been born.\n" to standard
output. ;)
And thus we complete the process.

Did I get it right?

Martin

--

Lew Pitcher, IT Consultant, Application Architecture
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)

[Mantorok Redgormor]

Da*****@cern.ch (Dan Pop) wrote in message news:<bj**********@sunnews.cern.ch>...

In <bj*************@news.t-online.com> Martin Dickopp <ex*************@zero-based.org> writes:

Richard Heathfield <do******@address.co.uk.invalid> writes:

#include <stdio.h>

int main(void)
{
printf("Happy Birthday, Dennis Ritchie. %d today.\n", ~0&0x1f<<1);
return 0;
}

Doesn't this program cause undefined behavior?

On a one's complement implementation, it's either undefined behaviour or
claiming that someone called Dennis Ritchie has just been born :-)

Dan

Joona Palaste said it performs two's complement. But I don't see how
~0 performs two's complement. When I take a look at the draft copy of
the standard it says that the result of ~ is the bitwise complement of
its operand. That means all bits are inverted. How does two's
complement come into play? and where is this stated in the standard
that ~ can be either one's complement or two's complement?

[Joona I Palaste]

Mantorok Redgormor <ne*****@tokyo.com> scribbled the following:

Da*****@cern.ch (Dan Pop) wrote in message news:<bj**********@sunnews.cern.ch>...

In <bj*************@news.t-online.com> Martin Dickopp <ex*************@zero-based.org> writes:

>Richard Heathfield <do******@address.co.uk.invalid> writes:
>> #include <stdio.h>
>>
>> int main(void)
>> {
>> printf("Happy Birthday, Dennis Ritchie. %d today.\n", ~0&0x1f<<1);
>> return 0;
>> }
>
>Doesn't this program cause undefined behavior?
On a one's complement implementation, it's either undefined behaviour or
claiming that someone called Dennis Ritchie has just been born :-)

Joona Palaste said it performs two's complement. But I don't see how
~0 performs two's complement. When I take a look at the draft copy of
the standard it says that the result of ~ is the bitwise complement of
its operand. That means all bits are inverted. How does two's
complement come into play? and where is this stated in the standard
that ~ can be either one's complement or two's complement?

Perhaps I should have explained in more detail. The ~ operator
implements one's complement arithmetic by inverting all the bits. Thus
you get "all-bits-one" for ~0, because "all-bits-zero" is 0.
But! If the number is signed, two's complement arithmetic comes into
play *after* that. On a two's complement machine, any number whose
leftmost bit is 1 is taken as negative, and "all-bits-one" is -1 on
such a machine. Therefore, on a two's complement machine, ~0 == -1.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"When a man talks dirty to a woman, that's sexual harassment. When a woman talks
dirty to a man, that's 14.99 per minute + local telephone charges!"
- Ruben Stiller

[Dan Pop]

In <bj*************@news.t-online.com> Martin Dickopp <ex*************@zero-based.org> writes:

Da*****@cern.ch (Dan Pop) writes:

In <bj*************@news.t-online.com> Martin Dickopp <ex*************@zero-based.org> writes:

>Richard Heathfield <do******@address.co.uk.invalid> writes:
>
>> #include <stdio.h>
>>
>> int main(void)
>> {
>> printf("Happy Birthday, Dennis Ritchie. %d today.\n", ~0&0x1f<<1);
>> return 0;
>> }
>
>Doesn't this program cause undefined behavior?
On a one's complement implementation, it's either undefined behaviour or
claiming that someone called Dennis Ritchie has just been born :-)

As far as I can see, it is implementation-defined whether or not `~0'
produces a trap representation on a one's complement implementation.
If it doesn't, it is unspecified if it produces a negative or normal
zero.

Correct, so far.
Before the `&' operator is evaluated, the result of `~0' is converted to
`unsigned int'.
Why? Both operands have type int.
Is my understanding of 6.3.1.3 correct that a negative
zero becomes a zero when converted to `unsigned int'?
It doesn't matter, because no such conversion occurs.
If I'm right so far, the expression `~0&0x1f<<1' either causes undefined
behavior (`~0' is a trap representation) or yields the value `0' on a
one's complement implementation.
Correct, even if you're not right so far ;-)
But even in the latter case, the type of `~0&0x1f<<1' is `unsigned int',
Why? All the operands involved have type int, so how can you end up with
an unsigned int result?!?
so the fact that it corresponds to a "%d" format specifier causes
undefined behavior.
The behaviour is well defined in this case, the expected output being
"Happy Birthday, Dennis Ritchie. 0 today.\n"
An implementation is therefore free to write the
string "Someone called Dennis Ritchie has just been born.\n" to standard
output. ;)

Which is a paraphrase of the actual output.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Keith Thompson]

And an image suddenly springs to mind of Dennis Ritchie standing
behind a podium at a C conference shouting "Get a life!".

Not that I'd be any more likely to follow that advice than anyone else
in this thread. 8-)}

--
Keith Thompson (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Martin Dickopp]

Da*****@cern.ch (Dan Pop) writes:

In <bj*************@news.t-online.com> Martin Dickopp <ex*************@zero-based.org> writes:

Da*****@cern.ch (Dan Pop) writes:

In <bj*************@news.t-online.com> Martin Dickopp <ex*************@zero-based.org> writes:

>Richard Heathfield <do******@address.co.uk.invalid> writes:
>
>> #include <stdio.h>
>>
>> int main(void)
>> {
>> printf("Happy Birthday, Dennis Ritchie. %d today.\n", ~0&0x1f<<1);
>> return 0;
>> }
>
>Doesn't this program cause undefined behavior?

On a one's complement implementation, it's either undefined behaviour or
claiming that someone called Dennis Ritchie has just been born :-)

As far as I can see, it is implementation-defined whether or not `~0'
produces a trap representation on a one's complement implementation.
If it doesn't, it is unspecified if it produces a negative or normal
zero.

Correct, so far.

Before the `&' operator is evaluated, the result of `~0' is converted to
`unsigned int'.

Why? Both operands have type int.

You are correct, of course. I have been severely confused.

Martin

[Rocke Robertson]

Joona I Palaste wrote:

Joona Palaste said it performs two's complement. But I don't see how
~0 performs two's complement. When I take a look at the draft copy of
the standard it says that the result of ~ is the bitwise complement of
its operand. That means all bits are inverted. How does two's
complement come into play? and where is this stated in the standard
that ~ can be either one's complement or two's complement?

Perhaps I should have explained in more detail. The ~ operator
implements one's complement arithmetic by inverting all the bits. Thus
you get "all-bits-one" for ~0, because "all-bits-zero" is 0.
But! If the number is signed, two's complement arithmetic comes into
play *after* that. On a two's complement machine, any number whose
leftmost bit is 1 is taken as negative, and "all-bits-one" is -1 on
such a machine. Therefore, on a two's complement machine, ~0 == -1.

Boy, I'm sure glad someone understands this stuff cause this last post by Joona just completely lost
me....

[Christopher Benson-Manica]

Joona I Palaste <pa*****@cc.helsinki.fi> spoke thus:

Perhaps I should have explained in more detail. The ~ operator
implements one's complement arithmetic by inverting all the bits. Thus
you get "all-bits-one" for ~0, because "all-bits-zero" is 0.

Is 0 indeed equivalent to 0x00000000? (I ask because I don't know...)

--
Christopher Benson-Manica | Jumonji giri, for honour.
ataru(at)cyberspace.org |

[Andreas Kahari]

In article <bj**********@chessie.cirr.com>, Christopher Benson-Manica wrote:
[cut]

Is 0 indeed equivalent to 0x00000000? (I ask because I don't know...)

For ints, yes.

The following FAQ entry is relevant to this:
http://www.eskimo.com/~scs/C-faq/q7.31.html

--
Andreas Kähäri

[Hallvard B Furuseth]

Christopher Benson-Manica wrote:

Is 0 indeed equivalent to 0x00000000? (I ask because I don't know...)

Yes. Both mean 0.

BTW, in case you were thinking that 0x00000000 is a special way to say
'all bits zero': Not so. (void*)0x00000000 means the same as (void*)0,
whose representation need not be all bits zero. The _integer_ 0 does
have all bits zero, though. Possibly except padding bits.

--
Hallvard

[Mark Gordon]

On Fri, 12 Sep 2003 19:43:25 +0000 (UTC)
Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote:

Joona I Palaste <pa*****@cc.helsinki.fi> spoke thus:

Perhaps I should have explained in more detail. The ~ operator
implements one's complement arithmetic by inverting all the bits.
Thus you get "all-bits-one" for ~0, because "all-bits-zero" is 0.

Is 0 indeed equivalent to 0x00000000? (I ask because I don't know...)

How could it not? The base of numbers in the source code does not affect
the value so 0==0x000000000000000000000000000000 and 15==0xf etc.

Or are you asking if the representation of 0 is specified by the
standard as being all bits zero?
--
Mark Gordon