51–60 of 126 posts
The link is an outdated version r0, this is r2 (don't know if it's the latest) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p090...
In April, the author of this proposal said on Twitter that the C++ standards committee agreed to this proposal for C++20: https://twitter.com/jfbastien/status/989242576598327296?lang...
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…
The compiler could help you more by emitting trapping arithmetic. Code that triggered signed overflow will probably not be "fixed" by this change alone. For example consider the classic binary search blunder: `mid = (low + high)/2`. Defining signed overflow may avoid the UB in computing mid, but now we have a surprise negative value and it's easy to guess what happens next. It will be fun to see the trophies from thi…
I find it amusing (and somewhat frustrating) that people who complain about risks from optimizations typically exhibit a lack of awareness of the tools that compilers already provide to diagnose related bugs.
Earlier quoted context omitted.
> for example, that (x&~1*2)/2 == x Fixed that for you.
No? If x is 3, then (x * 2) / 2 is also equal to 3 (as per the GP) but (x & ~1 * 2) / 2 is equal to 0. (If you meant ((x & ~1) * 2) / 2, then that is equal to 2).
So the compiler optimizable fix is something like: ((x & INT_MAX) * 2) / 2 = x
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.
Do such implementations currntly only abort on signed overflow and not on unsigned overflow? Aborting on unsigned overflow is currently not conforming, is it?
Getting rid of this useless (crap #!§$§$§$) legacy stuff was overdue, so i am very happy to see it done. I personally think it is _the_ most important proposal for C++20, since it will remove a lot of pointless pressure from secure coding attempts and in turn make the world a little bit more secure.
I'm curious why some old architectures didn't use two's complement for signed numbers. What advantage did one's complement or signed magnitude have over two's complement?
Don't forget negabinary! https://en.m.wikipedia.org/wiki/Negative_base Negabinary operations are extremely simple and elegant. Like 2s complement and 1s complement, it suffers from asymmetry in its range, though even more so.
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…
char * buf = malloc(size);
char * const buf = malloc(size);> 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…
Earlier quoted context omitted.
I think you are in agreement with the comment you are replying to.
The comment suggested the standard make it implementation defined rather than undefined. There's not a meaningful difference here. Even today, an implementation may define unsigned overflow.
That means that programmers don’t have to use trial and error to figure out how the compiler behaves and don’t have to _hope_ they found all the corner cases.