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:
[color=blue]
>
> 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>[/color]

No need for const. A template parameter is a compile-time constant anyway.
[color=blue]
> 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?[/color]

Yes.

"Rolf Magnus" <ramagnus@t-online.de> wrote in message
news:duh5oq$70t$01$1@news.t-online.com...
[color=blue][color=green]
>> 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?[/color][/color]
[color=blue]
> Yes.[/color]

Really? Can you tell us where that guarantee is?

Andrew Koenig wrote:[color=blue]
> "Rolf Magnus" <ramagnus@t-online.de> wrote in message
> news:duh5oq$70t$01$1@news.t-online.com...
>
>[color=green][color=darkred]
>>>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?[/color][/color]
>
>[color=green]
>>Yes.[/color]
>
>
> Really? Can you tell us where that guarantee is?[/color]

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:
[color=blue][color=green][color=darkred]
>>>>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?[/color]
>>
>>[color=darkred]
>>>Yes.[/color]
>>
>>
>> Really? Can you tell us where that guarantee is?[/color][/color]

Ok, maybe I forgot padding bits.
[color=blue]
> 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.[/color]

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

Rolf Magnus wrote:[color=blue]
> Victor Bazarov wrote:
>
>[color=green][color=darkred]
>>>>>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?[/color][/color]
>
>
> Ok, maybe I forgot padding bits.[/color]

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:
[color=blue]
> Rolf Magnus wrote:[color=green]
> > Victor Bazarov wrote:
> >
> >[color=darkred]
> > > > > > 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?[/color]
> >
> >
> > Ok, maybe I forgot padding bits.[/color]
>
> Padding bits? Do they exist outside the context of _bit fields_?[/color]

"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:
[color=blue]
> Rolf Magnus wrote:[color=green]
>> Victor Bazarov wrote:
>>
>>[color=darkred]
>>>>>>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?[/color]
>>
>>
>> Ok, maybe I forgot padding bits.[/color]
>
> Padding bits? Do they exist outside the context of _bit fields_?[/color]

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[color=blue]
> 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.[/color]

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:
[color=blue]
>
> 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[/color]
is[color=blue]
> 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[/color]
the[color=blue]
> Standard that the bit pattern in memory for all the aforementioned[/color]
types[color=blue]
> will be all zeros, ie. 0000 0000?
>
>
> -Tomás[/color]


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

[color=blue]
> The 2nd methos sets the pointer to "all bits zero" in memory, which may
> or may not represent "all bits zero" in memory.[/color]

Typo:

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

Andrew Koenig wrote:
[color=blue][color=green]
>> 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.[/color]
>
> 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.[/color]

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

"Tomás" <NULL@NULL.NULL> skrev i meddelandet
news:y2dPf.6842$j7.260884@news.indigo.ie...[color=blue]
>
> 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...
>[/color]

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

Andrew Koenig wrote:
[color=blue][color=green]
>> 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.[/color]
>
> Well, I can't find any place in the standard that prohibits sign-magnitude
> notation in which 0 represents negative and 1 represents positive.[/color]

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.

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

Diego Martins posted:
[color=blue]
> are there implementations where null pointers aren't zeros?
> which?
>
>[/color]

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