Hal Murray writes: > strom...@nexgo.de said: >> 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. > > I think all modern machines are using 2s complement arithmetic.
We already assume that for NTP. That is not the what I'm asking here. > That "implementation dependent" sort of weasel wording is probably > left over to cover that case. It might actually get interesting if > somebody ported a modern c compiler to work on one of those older > systems or an emulation of one. Again, when the value to be converted to signed is between [INT_MAX+1,UINT_MAX], then the implementation is free to either throw an error or do something else of it's own chosing. The question was if there is any implementation where the bit-for-bit representation actually changes. That would make things like (uint64_t)((int64_t)((uint64_t)v)) not return the same bits as v originally had. I know of no implementation that does something insane like always zeroing the sign bit, but the C99 normative wording doesn't preclude it. It just requires such a choice to be documented. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
