Zero always == 0000 0000

[Tomás]

Is the following fully legal and fully portable for all the unsigned
types? The aim of the function is to take an array by reference and set
each element's value to zero.

#include <...

template<class UnsignedNumericType, std::size_t const i>
void SetAllElementsToZero( UnsignedNumericType (&array)[i] )
{
memset( array, 0, i * sizeof(UnsignedNumericType) );

//or:

memset( array, 0, sizeof (array) );
}
I writing a function at the moment that's manipulating an array which is
passed to it by reference. It needs to set a certain amount of the
elements to zero. It will only ever be given the unsigned types, e.g.:

unsigned
unsigned char
unsigned short
unsigned long...
Is the code fully portable and well defined? Is there a guarantee in the
Standard that the bit pattern in memory for all the aforementioned types
will be all zeros, ie. 0000 0000?
-Tomás

[Rolf Magnus]

Tomás wrote:

Is the following fully legal and fully portable for all the unsigned
types? The aim of the function is to take an array by reference and set
each element's value to zero.

#include <...

template<class UnsignedNumericType, std::size_t const i>
No need for const. A template parameter is a compile-time constant anyway.
void SetAllElementsToZero( UnsignedNumericType (&array)[i] )
{
memset( array, 0, i * sizeof(UnsignedNumericType) );

//or:

memset( array, 0, sizeof (array) );
}
I writing a function at the moment that's manipulating an array which is
passed to it by reference. It needs to set a certain amount of the
elements to zero. It will only ever be given the unsigned types, e.g.:

unsigned
unsigned char
unsigned short
unsigned long...
Is the code fully portable and well defined? Is there a guarantee in the
Standard that the bit pattern in memory for all the aforementioned types
will be all zeros, ie. 0000 0000?

Yes.

[Andrew Koenig]

"Rolf Magnus" <ra******@t-online.de> wrote in message
news:du*************@news.t-online.com...

Is the code fully portable and well defined? Is there a guarantee in the
Standard that the bit pattern in memory for all the aforementioned types
will be all zeros, ie. 0000 0000?

Yes.

Really? Can you tell us where that guarantee is?

[Victor Bazarov]

Andrew Koenig wrote:

"Rolf Magnus" <ra******@t-online.de> wrote in message
news:du*************@news.t-online.com...

Is the code fully portable and well defined? Is there a guarantee in the
Standard that the bit pattern in memory for all the aforementioned types
will be all zeros, ie. 0000 0000?

Yes.

Really? Can you tell us where that guarantee is?

If we talk of straight 0, doesn't the fact that only three representations
are accepted (two's complement, one's complement, signed magnitude) serve
as the guarantee? Signed magnitude and one's complement have a way to
represent -0, but that's not what the OP asked.

V
--
Please remove capital As from my address when replying by mail

[Rolf Magnus]

Victor Bazarov wrote:

Is the code fully portable and well defined? Is there a guarantee in the
Standard that the bit pattern in memory for all the aforementioned types
will be all zeros, ie. 0000 0000?

Yes.

Really? Can you tell us where that guarantee is?

Ok, maybe I forgot padding bits.
If we talk of straight 0, doesn't the fact that only three representations
are accepted (two's complement, one's complement, signed magnitude) serve
as the guarantee? Signed magnitude and one's complement have a way to
represent -0, but that's not what the OP asked.

He didn't ask about signed types either, but rather only about unsigned
ones.

[Victor Bazarov]

Rolf Magnus wrote:

Victor Bazarov wrote:

>Is the code fully portable and well defined? Is there a guarantee in the
>Standard that the bit pattern in memory for all the aforementioned types
>will be all zeros, ie. 0000 0000?
Yes.
Really? Can you tell us where that guarantee is?

Ok, maybe I forgot padding bits.

Padding bits? Do they exist outside the context of _bit fields_?

V
--
Please remove capital As from my address when replying by mail

[Default User]

Victor Bazarov wrote:

Rolf Magnus wrote:

Victor Bazarov wrote:

> > > Is the code fully portable and well defined? Is there a
> > > guarantee in the Standard that the bit pattern in memory
> > > for all the aforementioned types will be all zeros, ie.
> > > 0000 0000?
>
>
> > Yes.
>
>
> Really? Can you tell us where that guarantee is?

Ok, maybe I forgot padding bits.

Padding bits? Do they exist outside the context of _bit fields_?

"Padding bits" would mean bits in an object that are used in the
representation of values. I believe C added something to the standard
that prohibits that sort of thing. Up until then, there was talk about
whether there could be unused bits that could form a trap
representation. Then 0 would not necessarily be all-bits-zero. This was
always pretty academic, as no one knew of any such implementation.

This is all my recollection, so any parts of it may be incorrect.

Brian

[Rolf Magnus]

Victor Bazarov wrote:

Rolf Magnus wrote:

Victor Bazarov wrote:

>>Is the code fully portable and well defined? Is there a guarantee in
>>the Standard that the bit pattern in memory for all the aforementioned
>>types will be all zeros, ie. 0000 0000?
>Yes.
Really? Can you tell us where that guarantee is?

Ok, maybe I forgot padding bits.

Padding bits? Do they exist outside the context of _bit fields_?

AFAIK, in integer types other than char and signed/unsigned char, not all
bits need to participate in its value representation. So in theory, there
could be a machine where an unsigned int with all bits (including the
padding ones) 0 could be a trap representation. That's the only thing I can
think of that Andrew could have been after in his answer to my posting. If
there is any other issue, maybe he could elaborate, because clearly, an
integer with all value-bits 0 does have a zero value.

[Andrew Koenig]

> If we talk of straight 0, doesn't the fact that only three representations

are accepted (two's complement, one's complement, signed magnitude) serve
as the guarantee? Signed magnitude and one's complement have a way to
represent -0, but that's not what the OP asked.

Well, I can't find any place in the standard that prohibits sign-magnitude
notation in which 0 represents negative and 1 represents positive. In such
a notation, all bits 0 means -0, which is presumably distinguishable from 0.

[Tomás]

Tomás posted:

Is the following fully legal and fully portable for all the unsigned
types? The aim of the function is to take an array by reference and set
each element's value to zero.

#include <...

template<class UnsignedNumericType, std::size_t const i>
void SetAllElementsToZero( UnsignedNumericType (&array)[i] )
{
memset( array, 0, i * sizeof(UnsignedNumericType) );

//or:

memset( array, 0, sizeof (array) );
}
I writing a function at the moment that's manipulating an array which is passed to it by reference. It needs to set a certain amount of the
elements to zero. It will only ever be given the unsigned types, e.g.:

unsigned
unsigned char
unsigned short
unsigned long...
Is the code fully portable and well defined? Is there a guarantee in the Standard that the bit pattern in memory for all the aforementioned types will be all zeros, ie. 0000 0000?
-Tomás

Anywho, what got me thinking of this is how you can't use this method
with pointers. For instance, take :

1) int* p = 0;

2) int* p;
memset(p,0,sizeof(int*) );
The 1st method sets the pointer to a "null pointer", which may or may not
represent "all bits zero" in memory.

The 2nd methos sets the pointer to "all bits zero" in memory, which may
or may not represent "all bits zero" in memory.

Actually come to think of it, if we've no guarantee that an unsigned
numeric type stores its zero value as "all bits zero", then we've not
guarantee that when we pass a zero literal (ie. 0) to memset, that it
will make the memory all bits zero...
-Tomás

[Tomás]

The 2nd methos sets the pointer to "all bits zero" in memory, which may
or may not represent "all bits zero" in memory.

Typo:

The 2nd method sets the pointer to "all bits zero" in memory, which may
or may not represent a "null pointer".

[Rolf Magnus]

Andrew Koenig wrote:

If we talk of straight 0, doesn't the fact that only three
representations are accepted (two's complement, one's complement, signed
magnitude) serve as the guarantee? Signed magnitude and one's complement
have a way to represent -0, but that's not what the OP asked.

Well, I can't find any place in the standard that prohibits sign-magnitude
notation in which 0 represents negative and 1 represents positive. In
such a notation, all bits 0 means -0, which is presumably distinguishable
from 0.

However, this is of no relevance, since the OP didn't ask about signed, but
rather only about unsigned types.

[Bo Persson]

"Tomás" <NU**@NULL.NULL> skrev i meddelandet
news:y2******************@news.indigo.ie...

2) int* p;
memset(p,0,sizeof(int*) );

Actually come to think of it, if we've no guarantee that an unsigned
numeric type stores its zero value as "all bits zero", then we've
not
guarantee that when we pass a zero literal (ie. 0) to memset, that
it
will make the memory all bits zero...

First, the 0 isn't unsigned, but a signed int. :-)

Also, it is converted to an unsigned char before it is stored. That
presumably takes care of any pad bits, as an unsigned char cannot have
any.
Bo Persson

[Rolf Magnus]

Andrew Koenig wrote:

If we talk of straight 0, doesn't the fact that only three
representations are accepted (two's complement, one's complement, signed
magnitude) serve
as the guarantee? Signed magnitude and one's complement have a way to
represent -0, but that's not what the OP asked.

Well, I can't find any place in the standard that prohibits sign-magnitude
notation in which 0 represents negative and 1 represents positive.

How about:

"The range of nonnegative values of a signed integer type is a subrange of
the corresponding unsigned integer type, and the value representation of
each corresponding signed/unsigned type shall be the same."

I don't see why this shouldn't include the zero value. So an unsigned 0 must
have the same value representation as a signed 0.

[Diego Martins]

are there implementations where null pointers aren't zeros?
which?

[Tomás]

Diego Martins posted:

are there implementations where null pointers aren't zeros?
which?

I don't know any off hand. What I do know is:

A) The Standard permits that a pointer not be all bits zero.

And from that, I'd speculate that they allowed this because there is in
fact a system where pointers aren't all bits zeros.

-Tomás