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]

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.

 

[Guest]

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)

 

[Guest]

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]

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.

 

[Old Wolf]

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

 

[Guest]

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.