Achim Gratz writes: > Hal Murray writes: >> Do any of the casts actually change any bits? (as compared to kill compiler >> warnings) > > As I understand it, C99 essentially mandates that the bit pattern is > preserved for integer casts to the extent that the number of bits allows > that. In particular if the two types have the same number of bits, then > casting back to the original type should yield the identical datum as > before the cast to another type.
So, I've gone back to the C99 standard (or rather the draft that WG14 put up on their website) and it turns out that this is a reasonable assumption on 2's complement machines and even explicitly mentioned in the informative parts of the document and the corresponding rationale, but normatively still implementation defined behaviour. Specifically, the unsigned->signed conversion is what invokes implementation defined behaviour when the unsigned value is larger than the *_MAX value associated with the signed type (6.1.3.1). The other direction is guaranteed to work correctly under the assumptions that NTP already makes elsewhere. GCC, as a shining example of conformance in this particular case, says this: "For conversion to a type of width N, the value is reduced modulo 2^N to be within range of the type; no signal is raised." https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html#Integers-implementation Does anybody know of an implementation that does _not_ preserve the representation when converting from signed to unsigned integer of the same width? The assumptions already made are: Corresponding signed and unsigned representation have the same number of bits, signed uses 2's complement representation, there are no extraordinary values and no padding bits in the representation. Also, I'd like waf to test that assumption upfront rather than the test suite to fail later if it wasn't true, but I have no idea how waf works in that regard. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
