On Wed Mar 9 02:11:21 EST 2011, fors...@terzarima.net wrote:
> >ah, that's the c type system.
>
> not exactly: ansi changed it.
> the original one had unsigned as an attribute that remained despite changes
> of word length.
> ansi changed it for various reasons to `value preserving' from `unsign
>ah, that's the c type system.
not exactly: ansi changed it.
the original one had unsigned as an attribute that remained despite changes of
word length.
ansi changed it for various reasons to `value preserving' from `unsigned
preserving'.
> 1 is signed. 1u is unsigned (see 6.4.4.1). 0x8000 doesn't
> fit in an int so it is an unsigned int. 0x1 won't fit
> in an unsigned int so it will pick the next type in the table
> that is big enough, which is long long int. Nice, eh?!
ah! i had just forgotten about the "too big to f
On Tue, 08 Mar 2011 12:16:29 EST erik quanstrom wrote:
> for this
>
> uvlong u, i;
>
> i = 31;
> u = 0xff00ull;
>
> i get
>
> u & 1< 0xff00ull
> u & 0x8000 -> 0
> u & (int)0x8000 -> 0xff00ull
>
If signedness matters, I use 1u or 1ul or 1ull. Doing so
will make your examples work as expected.
I don't pretend to understand the ansi rules and don't want
to devote the time to try to decode them.
>> so it seems clear that constants are treated as if unsigned, regardless,
>> but variables are not?
>
> the really wierd bit is that the 1 in 1< even though other constants are treated as if unsigned, and i is
> unsigned.
>
I would not hesitate to call that a bug.
I would also strongly advise
> so it seems clear that constants are treated as if unsigned, regardless,
> but variables are not?
the really wierd bit is that the 1 in 1<
for this
uvlong u, i;
i = 31;
u = 0xff00ull;
i get
u & 1< 0xff00ull
u & 0x8000 -> 0
u & (int)0x8000 -> 0xff00ull
u & -2147483648 -> 0
to put a finer point on it,
(u
