Double->unsigned conversion summary

[gwyn at brl-tgr.UUCP]

> Values		         1 2147483647 2147483648 2147483649 4294967295
> Came from	0x00000001 0x7fffffff 0x80000000 0x80000001 0xffffffff
> Turn into	0x00000001 0x7fffffff 0x80000000 0x80000001 0xffffffff
> Negated, into	0xffffffff 0x80000001 0x80000000 0x7fffffff 0x00000001
> Incremented,	0x80000001 0xffffffff 0x00000000 0x00000001 0x7fffffff
> Inc. & neg.,	0x7fffffff 0x00000001 0x00000000 0xffffffff 0x80000001
> 
> Doug suggests that this seems correct "according to the language rules,"
> and I agree. Actually, K&R state that "The result is undefined if the
> value will not fit in the space provided."  It may be undefined to the
> user, but compiler writers have to set it to SOMETHING.  To me (and,
> apparently, to DG) it makes some sense to have double->unsigned conversions
> wrap around in the same way as int->char and the like.

X3J11 has been a bit more thorough in specifying arithmetic conversions,
and my belief is that the above results agree with what they propose.

> Conclusion:  Don't assume that your compiler does what you would expect.
> As the guy used to say on Hill Street Blues, "Let's be careful out there."

Especially beware of Berkeley-based systems, which often use C compilers
derived from a PCC of approximately USG 3.0 vintage.  That compiler did
not properly propagate types through expressions.  (The same is true of
older Ritchie PDP-11 C compilers.)  Except for the ICON problem reported
some time ago, I have not experienced any unpleasant surprises due to the
SVR2 VAX PCC's interpretation of the C language rules.  One would hope
that PCC2 (which I do not have access to) is as reliable, but after your
posting of the results, this is less certain.  (Surely at least one of
those 3Bs must have used PCC2?)