Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
> paulh@odetics.com (Paul Hodgetts) writes:

>>Given the following code snippet:
>>
>> unsigned char a = 0x01;
>> unsigned char b = 0xFE;
>>
>> if (a == ~b) ...
>>
>>What should the comparison evaluate to -- true or false?

> false, unless `unsigned char' is the same as `unsigned int'.

Also false if `unsigned char' is the same as `unsigned int'.
--
Mike Rubenstein

rubenst%occs.nlm.nih.gov (Mike Rubenstein Phoenix Contract) writes:

>Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
>> paulh@odetics.com (Paul Hodgetts) writes:
>
>>>Given the following code snippet:
>>>
>>> unsigned char a = 0x01;
>>> unsigned char b = 0xFE;
>>>
>>> if (a == ~b) ...
>>>
>>>What should the comparison evaluate to -- true or false?
>
>> false, unless `unsigned char' is the same as `unsigned int'.
>
>Also false if `unsigned char' is the same as `unsigned int'.

Ah yes, because `unsigned int' is guaranteed to be at least 16 bits,
and so in that case the complement of 0x01 is not 0xFE.
Thanks for the correction.

--
Fergus Henderson - fjh@munta.cs.mu.oz.au
all [L] (programming_language(L), L \= "Mercury") => better("Mercury", L) ;-)

Given the following code snippet:

 unsigned char a = 0x01;
 unsigned char b = 0xFE;

 if (a == ~b) ...

What should the comparison evaluate to -- true or false?

I've been told that I need to code the comparison as

 if (a == (unsigned char) ~b) ...

because, in the first comparison, both a and b will be promoted to
unsigned ints (in our case 32 bits, so a = 0x00000001 and
b = 0x000000FE), then b will be bitwise negated to 0xFFFFFF01, thus
resulting in the first comparison evaluating to false when I expected
it to evaluate to true.  I've been told that this behavior is required
by the ANSI spec.  I have a copy of the 20 Sep 1994 draft, and I can't
seem to find anything saying this yet.

Would one of the ANSI Committee/Language gurus please set me straight
on this one (preferably with a reference to the appropriate spec
sections)?  Much thanks in advance!

Paul

----------------------------------------------------------------------
| Paul R. Hodgetts                 | email:  paulh@odetics.com       |
| ATL Products, An Odetics Company | phone:  (714) 758-0200 ext 4593 |
| 1515 S. Manchester Ave.          | fax:    (714) 774-3107          |
| Anaheim, CA, USA  92802-2907     |      (This Space for Rent)      |
----------------------------------------------------------------------
| Disclaimer:  Odetics is not responsible for anything I say or do!  |
----------------------------------------------------------------------

>>>>> Paul Hodgetts <paulh@odetics.com> writes:

> Given the following code snippet:
>  unsigned char a = 0x01;
>  unsigned char b = 0xFE;

>  if (a == ~b) ...

> What should the comparison evaluate to -- true or false?

> I've been told that I need to code the comparison as

>  if (a == (unsigned char) ~b) ...

> because, in the first comparison, both a and b will be promoted to
> unsigned ints (in our case 32 bits, so a = 0x00000001 and
> b = 0x000000FE), then b will be bitwise negated to 0xFFFFFF01, thus
> resulting in the first comparison evaluating to false when I expected
> it to evaluate to true.  I've been told that this behavior is required
> by the ANSI spec.  I have a copy of the 20 Sep 1994 draft, and I can't
> seem to find anything saying this yet.

  5.3.1  Unary operators                                 [expr.unary.op]

8 The operand of ~ must have integral or enumeration type; the result is
  the one's complement of its operand.   Integral  promotions  are  per-
  formed.  The type of the result is the type of the promoted operand.

Jason