[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: lua_number2int
- From: David Given <dg@...>
- Date: Tue, 14 Nov 2006 21:38:57 +0000
Brian Weed wrote:
> Jerome Vuarand wrote:
>> % make test
>> % test
> I get different results in VS2005...
You know, I've just had a horrible thought.
Does the C standard even *allow* you to cast an unsigned int to an int if the
value won't fit? Doesn't the result depend on your sign representation?
(0xFFFFFFFF == -1 only on two's-complement machines.) Are we seeing the
dreaded 'undefined behaviour'?
[rummages through the 'net]
Yes, I was right. This is from WG14 N1124, which is a reasonably current C99.
18.104.22.168 Signed and unsigned integers
¶1 When a value with integer type is converted to another integer type other
than _Bool, if the value can be represented by the new type, it is unchanged.
¶2 Otherwise, if the new type is unsigned, the value is converted by
repeatedly adding or subtracting one more than the maximum value that can be
represented in the new type until the value is in the range of the new type.
¶3 Otherwise, the new type is signed and the value cannot be represented in
it; either the result is implementation-deﬁned or an implementation-deﬁned
signal is raised.
22.214.171.124 Real ﬂoating and integer
¶1 When a ﬁnite value of real ﬂoating type is converted to an integer type
other than _Bool, the fractional part is discarded (i.e., the value is
truncated toward zero). If the value of the integral part cannot be
represented by the integer type, the behavior is undeﬁned.)
¶2 When a value of integer type is converted to a real ﬂoating type, if the
value being converted can be represented exactly in the new type, it is
unchanged. If the value being converted is in the range of values that can be
represented but cannot be represented exactly, the result is either the
nearest higher or nearest lower representable value, chosen in an
implementation-deﬁned manner. If the value being converted is outside the
range of values that can be represented, the behavior is undeﬁned.
Therefore, casting (double)0xFFFFFFFF to an unsigned int is valid, but it's
*not* valid to cast it to an int. Casting it to an unsigned int and *then* to
an int is valid, and will result in 0xFFFFFFF.
Anything else invoces undefined behaviour, and results in daemons flying out
of your nose.
╭─┈David Given┈──McQ─╮ "...electrons, nuclei and other particles are good
│┈ firstname.lastname@example.org┈┈┈┈│ approximations to perfectly elastic spherical
│┈(email@example.com)┈│ cows." --- David M. Palmer on r.a.sf.c
Description: OpenPGP digital signature