A one's complement sanity check, please

[Dan Henry]

I need a sanity check. The following is an exchange on
comp.arch.embedded with CBFalconer in a rather long MISRA related
thread. Since my little section of that thread and area of interest
was never really about MISRA, but rather the one's complement
representation of integer constant 0 and now how to zero memory
portably, I am bringing the topic to this group. Try to ignore CBF's
errors in the 1's complement -1 and sign magnitude -1 representations.
My questions are about 1's complement representation of the integer
constant 0. The exchange:

[exchange]
Dan Henry wrote:

CBFalconer <cb********@yahoo.comwrote:

>Dan Henry wrote:

>>CBFalconer <cb********@yahoo.comwrote:
Dan Henry wrote:
CBFalconer <cb********@yahoo.comwrote:
>
... snip ...

>>>>>Wrong. C representation may be sign/magnitude or 1's complement.
>>
>2's comp: -1 ----0x0001 ---0xffff
> ~ 1 ---~0x0001 ---0xffff (note NOT sign)
~ 0 ---~0x0000 ---0xffff "
>1's comp: -1 ----0x0001 ---0xffff
> ~ 1 ---~0x0001 ---0xfffe (note NOT sign)
~ 0 ---~0x0000 ---0xffff "
or ~ 0 ---~0xffff ---0x0000 "
>sign mag: -1 ----0x0001 ---0xffff
> ~ 1 ---~0x0001 ---0xfffe (note NOT sign)
~ 0 ---~0x0000 ---0xffff "
>>
>because of the rules for bringing unsigned into range.
>
~1? I read Marcin to be asking whether ~0 won't set all 1s.

See the additions above. Only -1 always returns 0xffff.

Isn't the integer constant 0 (lacking the unary - operator) in a
1's complement system positive zero, not negative zero? Doesn't
your second ~0 example actually represent ~-0?

In 1's complement -0 is equal to +0.

Right, but I am wondering about the predictability of the
underlying bit patterns.

Are you saying that in 1's complement the integer constant 0 could
have the bit pattern for +0 (all 0's) *or* the bit pattern for -0
(all 1's) and that using the unary - operator on the integer
constant 0 can yield either all 1's or all 0's -- that my
memset(&object, 0, sizeof object) is equally likely to zero all
bits as set all bits of the memory that object occupies?

Exactly.
[/exchange]

The implied conclusion is that memset(&object, 0, sizeof object) may
not zero a chunk of memory on a one's complement system. I'm having
an extremely difficult time accepting that. I don't interpret
6.2.6.2p2 to allow for (normal) 0 to have any nonzero bits in its
one's complement representation. I have never seen purportedly
portable code that does anything special with memset's second argument
to zero a chunk of memory. When using integer constant 0 as the
second argument to memset, I don't see how any of the operators listed
in 6.2.6.2p3 could possibly come into play to have changed normal 0
into negative 0. If integer constant 0 does in fact yield a nonzero
bit pattern, then the one portable way I can see to pass an all-zeroes
bit pattern as memset's second argument is:

#define ZERO (0^0)
memset(&object, ZERO, sizeof object);

But I don't see that in purportedly portable code. Or could my (0^0)
also be flawed as the above quoted exchange implies, because the first
0 in ZERO's expansion could be represented by all zeroes and the
second 0 in the expansion could be represented by all ones (or vice
versa). Wouldn't the translator stick to one representation or the
other and not flip willy-nilly? Or is it that the XOR operator being
in 6.2.6.2p3 means that (0^0) could yield negative zero?

Color me confused.

--
Dan Henry

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Dan Henry wrote:

I need a sanity check.
[...]
[exchange]
Dan Henry wrote:
[...]

Are you saying that in 1's complement the integer constant 0 could
have the bit pattern for +0 (all 0's) *or* the bit pattern for -0
(all 1's) and that using the unary - operator on the integer
constant 0 can yield either all 1's or all 0's -- that my
memset(&object, 0, sizeof object) is equally likely to zero all
bits as set all bits of the memory that object occupies?

Exactly.
[/exchange]

The implied conclusion is that memset(&object, 0, sizeof object) may
not zero a chunk of memory on a one's complement system. I'm having
an extremely difficult time accepting that.

And rightly so, for two different reasons. Firstly, memset converts
its second operand to an unsigned char. Even if plain 0 were allowed
to be negative 0, it would be converted to all bits zero, since
unsigned char has no sign bit and no padding bits. Secondly, plain 0
is not allowed to be negative 0 in the first place, because negative
zero "shall be generated only by:
-- the &, |, ^, ~, <<, and >operators with arguments that produce
such a value;
-- the +, -, *, /, and % operators where one argument is a negative
zero and the result is zero;
-- compound assignment operators based on the above cases." (C99
6.2.6.2p3)

[CBFalconer]

Dan Henry wrote:

>
I need a sanity check. The following is an exchange on
comp.arch.embedded with CBFalconer in a rather long MISRA related
thread. Since my little section of that thread and area of interest
was never really about MISRA, but rather the one's complement
representation of integer constant 0 and now how to zero memory
portably, I am bringing the topic to this group. Try to ignore CBF's
errors in the 1's complement -1 and sign magnitude -1 representations.
My questions are about 1's complement representation of the integer
constant 0. The exchange:

[exchange]
Dan Henry wrote:

>CBFalconer <cb********@yahoo.comwrote:

>>Dan Henry wrote:
CBFalconer <cb********@yahoo.comwrote:
Dan Henry wrote:
>CBFalconer <cb********@yahoo.comwrote:
>>
>... snip ...

>>>>>>Wrong. C representation may be sign/magnitude or 1's complement.
>>>
>>2's comp: -1 ----0x0001 ---0xffff
>> ~ 1 ---~0x0001 ---0xffff (note NOT sign)
~ 0 ---~0x0000 ---0xffff "
>>1's comp: -1 ----0x0001 ---0xffff
>> ~ 1 ---~0x0001 ---0xfffe (note NOT sign)
~ 0 ---~0x0000 ---0xffff "
or ~ 0 ---~0xffff ---0x0000 "
>>sign mag: -1 ----0x0001 ---0xffff
>> ~ 1 ---~0x0001 ---0xfffe (note NOT sign)
~ 0 ---~0x0000 ---0xffff "
>>>
>>because of the rules for bringing unsigned into range.
>>
>~1? I read Marcin to be asking whether ~0 won't set all 1s.
>
See the additions above. Only -1 always returns 0xffff.

Isn't the integer constant 0 (lacking the unary - operator) in a
1's complement system positive zero, not negative zero? Doesn't
your second ~0 example actually represent ~-0?

In 1's complement -0 is equal to +0.

Right, but I am wondering about the predictability of the
underlying bit patterns.

Are you saying that in 1's complement the integer constant 0 could
have the bit pattern for +0 (all 0's) *or* the bit pattern for -0
(all 1's) and that using the unary - operator on the integer
constant 0 can yield either all 1's or all 0's -- that my
memset(&object, 0, sizeof object) is equally likely to zero all
bits as set all bits of the memory that object occupies?

Exactly.
[/exchange]

The implied conclusion is that memset(&object, 0, sizeof object)
may not zero a chunk of memory on a one's complement system. I'm
having an extremely difficult time accepting that. I don't
interpret 6.2.6.2p2 to allow for (normal) 0 to have any nonzero
bits in its one's complement representation. I have never seen
purportedly portable code that does anything special with memset's
second argument to zero a chunk of memory. When using integer
constant 0 as the second argument to memset, I don't see how any
of the operators listed in 6.2.6.2p3 could possibly come into play
to have changed normal 0 into negative 0. If integer constant 0
does in fact yield a nonzero bit pattern, then the one portable
way I can see to pass an all-zeroes bit pattern as memset's second
argument is:

>From N869:

7.21.6.1 The memset function

Synopsis

[#1]

#include <string.h>
void *memset(void *s, int c, size_t n);

Description

[#2] The memset function copies the value of c (converted to
an unsigned char) into each of the first n characters of the
object pointed to by s.

Returns

[#3] The memset function returns the value of s.

>
#define ZERO (0^0)
memset(&object, ZERO, sizeof object);

But I don't see that in purportedly portable code. Or could my (0^0)
also be flawed as the above quoted exchange implies, because the first
0 in ZERO's expansion could be represented by all zeroes and the
second 0 in the expansion could be represented by all ones (or vice
versa). Wouldn't the translator stick to one representation or the
other and not flip willy-nilly? Or is it that the XOR operator being
in 6.2.6.2p3 means that (0^0) could yield negative zero?

Apart from the above I am going to stay out of this on this group.
At least for now. :-)

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net
--
Posted via a free Usenet account from http://www.teranews.com

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Harald van Dijk wrote:

Dan Henry wrote:

I need a sanity check.
[...]
[exchange]
Dan Henry wrote:
[...]

Are you saying that in 1's complement the integer constant 0 could
have the bit pattern for +0 (all 0's) *or* the bit pattern for -0
(all 1's) and that using the unary - operator on the integer
constant 0 can yield either all 1's or all 0's -- that my
memset(&object, 0, sizeof object) is equally likely to zero all
bits as set all bits of the memory that object occupies?

Exactly.
[/exchange]

The implied conclusion is that memset(&object, 0, sizeof object) may
not zero a chunk of memory on a one's complement system. I'm having
an extremely difficult time accepting that.

And rightly so, for two different reasons. Firstly, memset converts
its second operand to an unsigned char. Even if plain 0 were allowed
to be negative 0, it would be converted to all bits zero, since
unsigned char has no sign bit and no padding bits. Secondly, plain 0
is not allowed to be negative 0 in the first place, because negative
zero "shall be generated only by:
-- the &, |, ^, ~, <<, and >operators with arguments that produce
such a value;
-- the +, -, *, /, and % operators where one argument is a negative
zero and the result is zero;
-- compound assignment operators based on the above cases." (C99
6.2.6.2p3)

Sorry, after rereading your message, I see you are already aware of
this paragraph. In that case, I really don't even see why there might
be doubts.

[Dan Henry]

On 28 Apr 2007 11:42:25 -0700, Harald van D?k <tr*****@gmail.com>
wrote:

>Harald van D?k wrote:

>Dan Henry wrote:

I need a sanity check.
[...]
[exchange]
Dan Henry wrote:
[...]
Are you saying that in 1's complement the integer constant 0 could
have the bit pattern for +0 (all 0's) *or* the bit pattern for -0
(all 1's) and that using the unary - operator on the integer
constant 0 can yield either all 1's or all 0's -- that my
memset(&object, 0, sizeof object) is equally likely to zero all
bits as set all bits of the memory that object occupies?

Exactly.
[/exchange]

The implied conclusion is that memset(&object, 0, sizeof object) may
not zero a chunk of memory on a one's complement system. I'm having
an extremely difficult time accepting that.

And rightly so, for two different reasons. Firstly, memset converts
its second operand to an unsigned char. Even if plain 0 were allowed
to be negative 0, it would be converted to all bits zero, since
unsigned char has no sign bit and no padding bits. Secondly, plain 0
is not allowed to be negative 0 in the first place, because negative
zero "shall be generated only by:
-- the &, |, ^, ~, <<, and >operators with arguments that produce
such a value;
-- the +, -, *, /, and % operators where one argument is a negative
zero and the result is zero;
-- compound assignment operators based on the above cases." (C99
6.2.6.2p3)

Sorry, after rereading your message, I see you are already aware of
this paragraph. In that case, I really don't even see why there might
be doubts.

Doubts because although I am an extremely infrequent poster here, I am
a regular reader and use this newsgroup as an ongoing test of my
knowledge of the language even though I've been using the language
since the early '80s. When a regular c.l.c. poster, one seemingly
held in high regard, has a different viewpoint or interpretation of
the language, I doubt *my* knowledge first and try to research on my
own. This time after my research, I wasn't able to come to peace with
the discussion, so am seeking additional guidance.

--
Dan Henry

[Old Wolf]

On Apr 29, 6:38 am, Harald van Dijk <[e-mail]:

Secondly, plain 0 is not allowed to be negative 0 in the first place,
because negative zero "shall be generated only by:
-- the &, |, ^, ~, <<, and >operators with arguments that produce
such a value;
-- the +, -, *, /, and % operators where one argument is a negative
zero and the result is zero;
-- compound assignment operators based on the above cases." (C99
6.2.6.2p3)

Is (0^0) allowed to produce a negative zero? (It would be funny
if the original code were correct but the suggested 'fix' were wrong).

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Old Wolf wrote:

On Apr 29, 6:38 am, Harald van Dijk <[e-mail]:

Secondly, plain 0 is not allowed to be negative 0 in the first place,
because negative zero "shall be generated only by:
-- the &, |, ^, ~, <<, and >operators with arguments that produce
such a value;
-- the +, -, *, /, and % operators where one argument is a negative
zero and the result is zero;
-- compound assignment operators based on the above cases." (C99
6.2.6.2p3)

Is (0^0) allowed to produce a negative zero? (It would be funny
if the original code were correct but the suggested 'fix' were wrong).

"With arguments that produce such a value" means that -1^1 is allowed
to produce negative zero, not 0^0. 0 is all (non-padding) bits zero,
so 0^0 is all bits zero too, and all bits zero represents positive
zero.