[Mark] > I'm not sure how to decide which particular consequences > should be listed, but those for &, |, ^ and ~ could certainly > be included. [Martin] > It should give the CPython contributors an indication what kind > of code would be ok, and which would not. Perhaps it should include > both a black list and a white list: some may assume that two's > complement already provides guarantees on left-shift, when it > actually does not (**). Okay. I'll have to think about this a bit; I'll try to come up with some suitable wording. > (*) I wonder why you are not talking about padding bits > (6.2.6.2p1) Good point. Mostly because I haven't recently encountered any code where it matters, I suppose. But there's certainly CPython source that assumes no padding bits: long_hash in longobject.c is one example that comes to mind: it assumes that the number of value bits in an unsigned long is 8*SIZEOF_LONG. > (**) I also wonder why C fails to make left-shift > implementation-defined, perhaps with an even stronger binding > to the options for the integer representation. I wonder too. The C rationale document doesn't have anything to say on this subject. Mark
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4