Zero always == 0000 0000

Discussion in 'C++' started by Tomás, Mar 5, 2006.

  1. Tomás

    Tomás Guest

    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) )
    {
    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, Mar 5, 2006
    #1
    1. Advertising

  2. Tomás

    Rolf Magnus Guest

    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) )
    > {
    > 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, Mar 6, 2006
    #2
    1. Advertising

  3. "Rolf Magnus" <> wrote in message
    news:duh5oq$70t$01$-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?
    Andrew Koenig, Mar 6, 2006
    #3
  4. Andrew Koenig wrote:
    > "Rolf Magnus" <> wrote in message
    > news:duh5oq$70t$01$-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
    Victor Bazarov, Mar 6, 2006
    #4
  5. Tomás

    Rolf Magnus Guest

    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, Mar 6, 2006
    #5
  6. 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, Mar 6, 2006
    #6
  7. Tomás

    Default User Guest

    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
    Default User, Mar 6, 2006
    #7
  8. Tomás

    Rolf Magnus Guest

    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.
    Rolf Magnus, Mar 6, 2006
    #8
  9. > 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.
    Andrew Koenig, Mar 7, 2006
    #9
  10. Tomás

    Tomás Guest

    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) )
    > {
    > 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, Mar 7, 2006
    #10
  11. Tomás

    Tomás Guest


    > 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".
    Tomás, Mar 7, 2006
    #11
  12. Tomás

    Rolf Magnus Guest

    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.
    Rolf Magnus, Mar 7, 2006
    #12
  13. Tomás

    Bo Persson Guest

    "Tomás" <> skrev i meddelandet
    news:y2dPf.6842$...
    >
    > 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
    Bo Persson, Mar 7, 2006
    #13
  14. Tomás

    Rolf Magnus Guest

    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.
    Rolf Magnus, Mar 8, 2006
    #14
  15. are there implementations where null pointers aren't zeros?
    which?
    Diego Martins, Mar 8, 2006
    #15
  16. Tomás

    Tomás Guest

    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
    Tomás, Mar 8, 2006
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?SlJPQ2FtYXJv?=
    Replies:
    6
    Views:
    4,160
  2. Replies:
    0
    Views:
    10,180
  3. Zhiqiang Ye
    Replies:
    53
    Views:
    10,215
    Dan Pop
    Jun 28, 2004
  4. Gerard Flanagan
    Replies:
    3
    Views:
    428
    Terry Hancock
    Nov 19, 2005
  5. =?Utf-8?B?V2VlIEt1YW4=?=
    Replies:
    0
    Views:
    3,013
    =?Utf-8?B?V2VlIEt1YW4=?=
    Nov 20, 2006
Loading...

Share This Page