It seems like a sensible simplification to me. Is there any architecture that doesn't use twos complement (eg. uses separate sign bit + magnitude) and could run C code?
I think such machines are pretty much a thing of the past. This topic cropped up in a 2018 thread when C++ made the same change. [0]
> Overflowing operations and out-of-range conversion are generally mapped to modulo operations and cannot trap or raise signals.
This would be a problem on x86, where INT_MIN / -1 causes a #DE (divide error) exception. In C17 that is fine because signed integer overflow is undefined behaviour. But if the behaviour is defined, that trap would have to be caught or avoided.
The best solution for performance would be to have a new trap handler. That would have to parse the instruction to find its length, and the divisor (in memory or register) to differentiate it from division by zero, write the constant result and remainder into the destination registers (always rax and rdx thankfully) and then continue with the next instruction.
But I think this could be difficult to do in a fool-proof way, with how CPU exceptions are handled in different operating systems. Some operating systems might not even allow it at all.
“[The C++ standardization committee] WG21 has recently adapted the changes promoted in their document p12363. Generally, C++ goes much beyond what is presented here:”
I would be extremely surprised if the proposal to make signed arithmetic overflow defined behavior in C made it into C23. The window is narrowing and this would be a very big change to the language. Making it official that 2's complement is the only representation for signed integers is already a large change.
Later in the decade, maybe.
Overflow of signed integer types remains undefined behaviour in both C and C++. A compiler is free to make a promise like signed integer overflow is always handled with wrapping or signed integer overflow is always handled with saturation. (GCC has a flag, -fwrapv, to enable guaranteed wrapping. [1])
[0] https://stackoverflow.com/a/25664954/
[1] https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html
I'm glad the terrible "defer" suggestion didn't make it, but unfortunate that they didn't standardise the existing and widely used attribute cleanup.
If you want to link to a thread, you should click on the first tweet of that thread and copy its url. It's easy to see the rest of the thread: just scroll down.
If you want to link to one tweet in a thread you should click on that tweet and copy its url.
The person who posted the link to HN did the latter, while they should have done the former.
Twitter could make it easier to see that a tweet is part of a thread though.
It's easy to see all of the tweets made by the author, at least those made as replies to themselves, but reading the actual threads is hard or impossible. At least I haven't figured out how to do it despite considerable effort.
For example, say you want to view the replies to the tweet above the linked tweet, the one about "assert". There are supposedly 4 replies. If you tap that tweet you remain in the same list of self-replied tweets. There are replies at the end, but are they replies to the tweet you want to focus on? It doesn't look like it, but who knows, maybe? It's even worse on linger Twitter self-reply "threads".
I don't know how Twitter's engineers got the well-established threading pattern so wrong. This behavior doesn't even increase the number of ads you see.
https://twitter.com/__phantomderp/status/1494801365297676293
Edit: I think one of these could be a better link: https://en.cppreference.com/w/c/23 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2864.pdf