Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Signed Integers Are Two’s Complement

open-std.org

Post reply on HN
Print view View original

41–50 of 126 posts

Re: Signed Integers Are Two’s Complement

#41

Post by rom1v »

cjensen wrote: post #13
greenhouse_gas wrote: post #7

The real issue isn't that C doesn't have a standard int overflow, but that it's undefined. What they could have done is made it implementation defined , like sizeof(int), which depends on the implementation (hardware) but on the other hand isn't undefined behavior (so on x86/amd4 sizeof(int) will always be equal to 4).

It's undefined for a reason. size_t size = unreasonable large number; char buf = malloc (size); char *mid = buf + size / 2; int index = 0; for (size_t x = 0; x A common optimization by a compiler is to introduce a temporary char *temp = mid + index; prior to the loop and then replace the body of the loop with *(temp++) = x; If the compiler has to worry about integer overflow, this optimization is not valid. (I'm not…

size_t is unsigned, overflow is defined.

Re: Signed Integers Are Two’s Complement

#42

Post by exDM69 »

userbinator wrote: post #24
garmaine wrote: post #11

Earlier quoted context omitted.

In addition to what's mentioned in the already great sibling comments, it's worth noting that IEEE floating point is signed-magnitude.

Sign-magnitude for the significand, and offset-binary for the exponent. The reason for this odd combination is probably historical.

It's also practical for hw implementation and has other nice qualities. E.g. comparisons and sorting are easy. Radix sort works for floating point (with some bit magic). Terms and conditions may apply (oddities w.r.t. INF, Nan, etc).

Re: Signed Integers Are Two’s Complement

#43

Post by jgtrosh »

Quick question: in the proposed rewording of intro.execution¶8, why is the following rewriting “((a + b) + 32765)” not reintegrated at the end of the untouched text? Have I misunderstood that with two's complement this would be legal?

Re: Signed Integers Are Two’s Complement

#44

Post by raverbashing »

> Naïve overflow checks, which are often security-critical, often get eliminated by compilers. This leads to exploitable code when the intent was clearly not to and the code, while naïve, was correctly performing security checks for two’s complement integers.

This is the most critical aspect. We have enough trouble already without the compiler actually fighting against security because this would fail in a machine from the 70s

Re: Signed Integers Are Two’s Complement

#46

Post by caf »

microcolonel wrote: post #29

The equivalent for C/WG14: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm

That document has this listed as a Change:

Conversion from signed to unsigned is always well-defined: the result is the unique value of the destination type that is congruent to the source integer modulo 2ⁿ.

...but that's not a change - it's been the case in C all along.

Re: Signed Integers Are Two’s Complement

#47

Post by simias »

DoofusOfDeath wrote: post #31
caf wrote: post #25

Earlier quoted context omitted.

However it also prevents "abort on overflow" implementations from being conforming, which look like a much better way of finding actual overflow bugs in the code.

That's a question of static vs. dynamic analysis for bug detection. Which one(s) is/are most useful depends on the user's needs.

Static analysis was always possible, dynamic isn't if you want to remain standard-compliant and overflow is defined.

That being said I think it's a rather weak justification for making overflow UB, after all if you want to trap on overflows wouldn't want to catch unsigned overflow as well?

Re: Signed Integers Are Two’s Complement

#48

Post by sanxiyn »

ridiculous_fish wrote: post #15

> Overflow in the positive direction shall wrap around This appears to be defining signed integer overflow semantics, which prevents the compiler from doing certain basic optimizations, for example, that (x*2)/2 == x. Is that part of this? Has anyone measured the perf cost on a real program?

The link is revision 0. Revision 1 reverted defining signed integer overflow. In revision 1, signed integer overflow is still undefined, precisely for this reason.

Re: Signed Integers Are Two’s Complement

#49

Post by mort96 »

caf wrote: post #25
userbinator wrote: post #17

Earlier quoted context omitted.

It prevents risky optimisations; this now requires the compiler to prove that such optimisations won't change the semantics of the code, e.g. in your case by essentially proving that the high 2 bits of x (only 1 in the unsigned case, due to sign-extension) will never be set. ...and it could be argued that if the compiler couldn't prove that was true, then it just helped you find a possible overflow bug in the code. I…

However it also prevents "abort on overflow" implementations from being conforming, which look like a much better way of finding actual overflow bugs in the code.

Do such implementations currntly only abort on signed overflow and not on unsigned overflow? Aborting on unsigned overflow is currently not conforming, is it?

Re: Signed Integers Are Two’s Complement

#50

Post by sanxiyn »

raverbashing wrote: post #44

> Naïve overflow checks, which are often security-critical, often get eliminated by compilers. This leads to exploitable code when the intent was clearly not to and the code, while naïve, was correctly performing security checks for two’s complement integers. This is the most critical aspect. We have enough trouble already without the compiler actually fighting against security because this would fail in a machine fr…

This got rejected in the next revision of this proposal. Naive overflow checks are still undefined.
Post reply on HN