Message161759
> It seems the patch relies on a two's complement representation of
> integers. Mark, do you think that's ok?
(1) Relying on two's complement integers seems fine to me: we're already relying on it in other places in Python (e.g., bitwise operations for ints in Python 2.x); it seems unlikely Python's going to run into current or future hardware that uses anything else; and any special-case code for ones' complement or sign-magnitude is going to be essentially unused and awkward to test, so it's probably better not to have it in the codebase at all.
In an ideal world, I guess we'd add some configure-time tests for two's complement so that in the unlikely event that Python *does* meet a non two's complement platform the build fails early with a clear message rather than the tests failing in strange ways.
(2) The bit that Martin identifies: relying on conversion from unsigned to signed doing a wraparound modulo 2**<suitable n> is a bit more troubling; it's something that I try to avoid where possible, but that's not always easy. I don't recall ever having encountered this causing problems in practice, though---it feels like a leftover from a non-two's complement world where processors would have a hard time giving wraparound semantics, so the C standard didn't want to require it. Again, if we're going to rely on this, it would probably make sense to have some configure-time checks; and it would be better not to rely on it at all without a really good reason. |
|
Date |
User |
Action |
Args |
2012-05-28 06:42:52 | mark.dickinson | set | recipients:
+ mark.dickinson, loewis, jcea, ronaldoussoren, janssen, pitrou, vstinner, ned.deily, ezio.melotti, Arfrever, python-dev, serhiy.storchaka |
2012-05-28 06:42:52 | mark.dickinson | set | messageid: <1338187372.23.0.927200202019.issue14923@psf.upfronthosting.co.za> |
2012-05-28 06:42:50 | mark.dickinson | link | issue14923 messages |
2012-05-28 06:42:49 | mark.dickinson | create | |
|