A one's complement sanity check, please
- From: Dan Henry <usenet@xxxxxxxxxxxxx>
- Date: Sat, 28 Apr 2007 11:43:50 -0600
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 <cbfalconer@xxxxxxxxx> wrote:
Dan Henry wrote:
CBFalconer <cbfalconer@xxxxxxxxx> wrote:
Dan Henry wrote:
CBFalconer <cbfalconer@xxxxxxxxx> wrote:... snip ...
~ 0 ---> ~0x0000 ---> 0xffff "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)
or ~ 0 ---> ~0xffff ---> 0x0000 "
~ 0 ---> ~0x0000 ---> 0xffff "sign mag: -1 ---> -0x0001 ---> 0xffff
~ 1 ---> ~0x0001 ---> 0xfffe (note NOT sign)
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
.
- Follow-Ups:
- Re: A one's complement sanity check, please
- From: Harald van Dijk
- Re: A one's complement sanity check, please
- From: CBFalconer
- Re: A one's complement sanity check, please
- Prev by Date: Re: two meanings of a cast
- Next by Date: Re: A one's complement sanity check, please
- Previous by thread: Common Routine To Call (Almost) Identical Functions
- Next by thread: Re: A one's complement sanity check, please
- Index(es):
Relevant Pages
|
