Re: Quick check on signed promotion of bytes
- From: "Tomás Ó hÉilidhe" <toe@xxxxxxxxxxx>
- Date: Thu, 31 Jan 2008 17:17:16 GMT
Eric Sosman:
1) x is promoted to signed int.
2) The complement is take of this signed int.
3) This signed int is then converted to an unsigned char
That's right, under your assumptions. On "exotic" machines
where UCHAR_MAX > INT_MAX (for example, on hardware where all
of char, short, and int are 16 bits wide), then x promotes to
an unsigned int instead of to an int in step 1.
So just to confirm if I'm thinking right. We start off with:
char unsigned x, y;
x = 0xf0;
y = ~x;
What we _want_ this code to do is to give us the value 0x0f for y (i.e.
the complement of x). However what _could_ happen is:
1) x is promoted to signed int.
=> Now we have a signed int with the value 0xf0
2) The complement is taken of this signed int.
=> Now we have some other number that is negative. The exact number
depends on the number system in use (e.g. sign-magnitude), and
also the amount of bits in an int.
3) The signed int is converted to an unsigned char.
=> This process is well-defined, but we don't know what signed
value we have.
Therefore, it is my assumption that will not give the desired behaviour
on every implementation of the Standard -- we could get something
totally different from 0x0f as an answer (even on an 8-bit-byte system).
That sound right?
--
Tomás Ó hÉilidhe
.
- Follow-Ups:
- Re: Quick check on signed promotion of bytes
- From: Eric Sosman
- Re: Quick check on signed promotion of bytes
- References:
- Quick check on signed promotion of bytes
- From: toe
- Re: Quick check on signed promotion of bytes
- From: Eric Sosman
- Quick check on signed promotion of bytes
- Prev by Date: Re: assigning pointer to NULL
- Next by Date: Re: A solution for the allocation failures problem
- Previous by thread: Re: Quick check on signed promotion of bytes
- Next by thread: Re: Quick check on signed promotion of bytes
- Index(es):
Relevant Pages
|