Front page | perl.perl5.porters |
Postings from May 2012
Nicholas Clark wrote: > *Signed* integer overflow, however, is undefined >behaviour (not just implementation defined or unspecified) so really isn't >something we should be doing. ... >Whilst right now compilers usually end up exposing the behaviour of the >underlying CPU (which is nearly always 2s complement these days) the core's >code is making this assumption, but should not. The core code assumes an awful lot about the representation of the basic data types, pointer arithmetic, and similar matters. That signed integers are twos-complement and that signed arithmetic wraps is a relatively mild one. I don't think eliminating that assumption throughout the core is useful. Trapping overflow might still be useful as a debugging technique in particular parts of the code, however. >1) The assumption that the signed bit pattern for the most negative signed > value, IV_MIN, is identical to the bit pattern for the unsigned negation > of that value. ie on a 32 bit system, the IV -2147483648 and the > UV 2147483648 have the same bit representation Believe it or not, this actually nearly *is* guaranteed by the C standard. The constraints on signed integer representation tie it closely to the corresponding unsigned type. Both types in a signed/unsigned pair must use the same bits, in the same order of significance, and both must be pure binary. The only sign schemes known to conform are twos-complement, ones-complement, and sign-magnitude; there's no explicit restriction to these, but no one's ever come up with anything else that would qualify. Now, in ones-complement and sign-magnitude IV_MIN == -IV_MAX, whereas in twos-complement IV_MIN == -IV_MAX-1. I think we rely on the latter, and so indirectly rely on twos-complement. With the other representation guarantees of the standard, twos-complement *does* imply that IV_MIN has exactly the same representation as the UV -IV_MIN. -zeframThread Previous