lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Am 08.07.2013 15:15 schröbte Roberto Ierusalimschy:
That may not do what is expected, because it involves
implementation-defined behavior: 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 " 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
bits unchanged)?

Both gcc[1] and msvc[2] seem to have the required behavior. According to Linus Torvalds[3], this is the only sane choice for two's complement machines, and Wikipedia says that by now virtually everyone has adopted two's complement. 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[4], but AFAICT it is only guaranteed to work for C99 and up ...


-- Roberto