5 ms·

> Any reasonable person would look at the standard and conclude there is no other implicit intent than to describe a standard. That's complete nonsense. If th

by xscott 4y ago

> Any reasonable person would look at the standard and conclude there is no other implicit intent than to describe a standard. That's complete nonsense. If there wasn't intent, it would just be random words making random rules. There was a reason and motivation behind the creation of those rules, and reasonable people can at least speculate about the motivation. > If you are reasoning on any other machine that the C virtual machine, _you_ are wrong. The underscore is very dramatic. :-) > If you want to reason about X86, use assembly. Higher level languages are not coupled to any particular hardware. I never said anything about X86. I think maybe you're reliving an argument with someone else. However, all of i686, AMD64, ARM, AArch64, PowerPC, RISC-V, Alpha, PA-RISC, or any mass market server, desktop, laptop, or smartphone in the last 30 years have one address space and use 2's complement for signed integers. It's a choice for a high level language to pretend that's not true.

tempodox 4y ago
It's a choice to pretend that other architectures cannot exist, or if they do, you can't port C to them.
pif 4y ago
> all of ... in the last 30 years have one address space and use 2's complement for signed integers Yes, they do. The C virtual machine never did and never will.
- bonzini 4y ago
  Incorrect, C2x will and that matters for casts from unsigned to signed. But signed overflow will remain undefined
pif 4y ago
> It's a choice for a high level language to pretend that's not true. It's a choice C did since its inception: stop whining and accept the fact, please!
- xscott 4y ago
  Again, so dramatic with the explanation point. :-) You do know your posting history is readable to all of us, right? It's very clear that your game is to post a 1 or 2 line snipe to try and antagonize people. You do you, but I'm not whining, and you're just trolling. Best wishes.
bonzini 4y ago
The next version of C will have twos-complement only. But that has nothing to do with overflow being undefined; you could make it implementation-defined if all you cared about was -magnitude and ones-complement representation, or saturating arithmetic.
- xscott 4y ago
  > But that has nothing to do with overflow being undefined; That's not the whole story [0]. It looks like JF Bastien managed to convince everyone that 2's complement is the only signed representation that exists and is worth considering, and so pretending to be portable to anything else is pointless. But then he met "strong resistance" trying to finish the job: The author had hoped to make this well-defined as wrapping (the operations produce the same value bits as for the corresponding unsigned type), but WG21 had strong resistance against this. So at least one standards person tried to achieve sanity, but he was overwhelmed or outnumbered by the rest of the asylum. For a stand alone application, -fwrapv makes this silliness go away. However, if I want to write a library where I don't get to control the options my end users select, we're going to end up with silliness like this: struct integer { intptr_t val; }; integer operator +(integer lhs, integer rhs) { return (integer) { intptr_t(uintptr_t(lhs.val) + uintptr_t(rhs.val)) }; } There. Now I've got sane integers. Compliant, and I'll bet it optimizes just as well. [0[] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r4.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p09...
  - bonzini 4y ago
    > So at least one standards person tried to achieve sanity At the cost of real-world pessimization of generated code. It's basically impossible to optimize induction variables without undefined signed overflow, and it's possibly the most important optimization for C code, maybe after inlining and simple manipulations such as dead code elimination. On the other hand, defining right shift of negative numbers is now a no brainer. No compiler even thought of exploiting UB there, and C2X will codify that. > Compliant, and I'll bet it optimizes just as well. Try, you will be surprised.

by xscott 4y ago

tempodox 4y ago

It's a choice to pretend that other architectures cannot exist, or if they do, you can't port C to them.

pif 4y ago

> all of ... in the last 30 years have one address space and use 2's complement for signed integers Yes, they do. The C virtual machine never did and never will.

bonzini 4y ago
Incorrect, C2x will and that matters for casts from unsigned to signed. But signed overflow will remain undefined

pif 4y ago

> It's a choice for a high level language to pretend that's not true. It's a choice C did since its inception: stop whining and accept the fact, please!

xscott 4y ago
Again, so dramatic with the explanation point. :-) You do know your posting history is readable to all of us, right? It's very clear that your game is to post a 1 or 2 line snipe to try and antagonize people. You do you, but I'm not whining, and you're just trolling. Best wishes.

bonzini 4y ago

The next version of C will have twos-complement only. But that has nothing to do with overflow being undefined; you could make it implementation-defined if all you cared about was -magnitude and ones-complement representation, or saturating arithmetic.

xscott 4y ago
> But that has nothing to do with overflow being undefined; That's not the whole story [0]. It looks like JF Bastien managed to convince everyone that 2's complement is the only signed representation that exists and is worth considering, and so pretending to be portable to anything else is pointless. But then he met "strong resistance" trying to finish the job: The author had hoped to make this well-defined as wrapping (the operations produce the same value bits as for the corresponding unsigned type), but WG21 had strong resistance against this. So at least one standards person tried to achieve sanity, but he was overwhelmed or outnumbered by the rest of the asylum. For a stand alone application, -fwrapv makes this silliness go away. However, if I want to write a library where I don't get to control the options my end users select, we're going to end up with silliness like this: struct integer { intptr_t val; }; integer operator +(integer lhs, integer rhs) { return (integer) { intptr_t(uintptr_t(lhs.val) + uintptr_t(rhs.val)) }; } There. Now I've got sane integers. Compliant, and I'll bet it optimizes just as well. [0[] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r4.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p09...
- bonzini 4y ago
  > So at least one standards person tried to achieve sanity At the cost of real-world pessimization of generated code. It's basically impossible to optimize induction variables without undefined signed overflow, and it's possibly the most important optimization for C code, maybe after inlining and simple manipulations such as dead code elimination. On the other hand, defining right shift of negative numbers is now a no brainer. No compiler even thought of exploiting UB there, and C2X will codify that. > Compliant, and I'll bet it optimizes just as well. Try, you will be surprised.