«

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

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.

"Rolf Magnus" <> wrote in message
news:duh5oq$70t$01$...

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

Andrew Koenig wrote:
> "Rolf Magnus" <> wrote in message
> news:duh5oq$70t$01$...
>
>
>>>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

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.

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

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

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.

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