On Tue, Dec 1, 2009 at 4:47 PM, Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote: >> On Tue, Dec 1, 2009 at 4:17 PM, James Y Knight <foom at fuhm.net> wrote: >>> I think all that needs to be defined is that conversion from unsigned to signed, and (negative) signed to >>> unsigned integers have 2's complement wrapping semantics, and does not affect the bit pattern in memory. > > > I don't know if this particular implementation defined behavior is > safe to be relied upon. I just want to suggest that if any such > assumption is made in the code, a test should be added to configure to > complain loudly if a platform violating the assumption is found in the > future. That sounds like a good idea. An extension of that would be to define an UNSIGNED_TO_SIGNED macro (insert better name here) which, depending on the result of the configure test, either used a direct cast or a workaround. E.g., for an unsigned long x, ((x) >= 0 ? (long)(x) : ~(long)~(x)) always gives the appropriate wraparound semantics (I think), assuming two's complement with no trap representation. 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