[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] Lua 5.3.0 (work1) now available
- From: Philipp Janda <siffiejoe@...>
- Date: Mon, 08 Jul 2013 23:30:06 +0200
Am 08.07.2013 15:15 schröbte Roberto Ierusalimschy:
That may not do what is expected, because it involves
22.214.171.124 Signed and unsigned integers [...] When an integer is
demoted to a signed integer with smaller size, or an unsigned
integer is converted to its corresponding signed integer, if the
value cannot be represented the result is implementation-defined.
If I remember right, you can work around this with a memcpy() from the
unsigned variable to the signed variable.
I can't say for C90, but in C99 and up this won't work: For one's
complement or sign-magnitude architectures, or if the signed type has
more padding bits than the corresponding unsigned type, the result would
just be wrong. In the latter case you could also generate trap
representations by accident. (The gory details are in C99 "126.96.36.199
Representations of types -> Integer types").
Before trying to solve a problem, let us be sure there is a
problem. Have anyone ever used a C implementation where the conversion
from unsigned int to int did not have the "expected" behavior (keep the
Both gcc and msvc seem to have the required behavior. According to
Linus Torvalds, this is the only sane choice for two's complement
machines, and Wikipedia says that by now virtually everyone has adopted
So we can probably risk waiting for the first bug report, but IMHO this
would be a good use case for an `assert` somewhere.
There is also this stackoverflow solution, but AFAICT it is only
guaranteed to work for C99 and up ...