lfpinit() signed or unsigned?

[Achim Gratz]

Hal Murray writes:
> Stromeko at 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