3 ms·
If a signed operation would naturally produce a value that is not within the range of the result type, the behavior is undefined. The author had hoped to make t
by dzdt 8y ago
If a signed operation would naturally produce a value that is not within the range of the result type, the behavior is undefined. 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.
Who are the standards committee people having strong resistance against this, and what in the world is their argument?
- kazinator 8y agoUndefined doesn't mean incorrect; it's just the absence of a requirement. A compiler writer can add requirements locally (like "signed integer overflows have wrapping behavior") that are missing in the standard. The standard is not a suitable babysitting tool for GCC maintainers, which is what I suspect is the motivation here.
- yoklov 8y agoThis isn’t entirely untrue in theory, but in practice it is. Compilers optimize under the assumption that undefined behavior never occurs, and the standard is written with this assumption. Any conforming compiler is free to break code that relies on this. Typically, behavior that reasonably may vary from compiler/machine is considered implementation defined, and not undefined.
- kazinator 8y ago> Any conforming compiler is free to break code that relies on this. Ah, but, for example, __attribute__((packed)) is undefined behavior; is the compiler free to break that? This "free to break" is a juvenile fiction based on the idea that the only document that applies is ISO C; there is no other contract or promise between user and implementor.
- sanxiyn 8y agoGCC documentation is another such contract, which provides -fwrapv. If you want -fwrapv, use -fwrapv.
- sanxiyn 8y agoI am not sure why people pick GCC in particular for this issue. LLVM does exactly the same.