Earlier quoted context omitted.
Yes, see JavaScript: https://www.w3schools.com/js/js_numbers.asp
JS is IEEE754, not a (one's or two's) complement-based representation.
Ah I misunderstood the question.
Signed Integers Are Two’s Complement
121–126 of 126 posts
Re: Signed Integers Are Two’s Complement
#122Earlier quoted context omitted.
It's done so that the bits will compare the same way whether treated as float or int. (modulo NaNs and stuff)
That is only true for non-negative floating point numbers. It's still useful though. Interestingly, posits as originally proposed do have this property (except for infinity).
Would have been nice if IEEE stored the complement sign.
Re: Signed Integers Are Two’s Complement
#123Earlier quoted context omitted.
Don't leave out the last part: ...was correctly performing security checks for two’s complement integers. More pedantically, they could have written: ...was correctly performing security checks if the standard had been limited to two’s complement integers. But that was clearly the intent.
But the revised version is limited to twos complement and is still undefined, so such a check is still incorrect.
Okay, you may be right; I haven't looked through all diffs in detail (nor do I understand all intricacies of the standard).
Re: Signed Integers Are Two’s Complement
#124> 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…
By all means, make the change for the new version of the language. In the meantime, though, why are people assuming two's complement?!
General knowledge. Have you read the entire standard? I haven't, but I know my machine uses two's complement internally, and C and C++ are generally supposed to be close to the bare metal.
Re: Signed Integers Are Two’s Complement
#125Getting 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 don't see how. Integer overflows still can be security issues even if they wrap.
There will always be unavoidable issues, since C/C++ is a system language, designed to survive under tight performance pressure.
The point here is, to remove pointless obstacles.
Re: Signed Integers Are Two’s Complement
#126There seems to be an error in this proposal:
"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 2N."
This is no change, since we have that already, e.g. see https://en.cppreference.com/w/cpp/language/implicit_conversi... and the conversion operation on the bit pattern is the identity for two's complement representation. The relevant section in the latest C++ standard is: 4.8 Integral conversions [conv.integral] 1 A prvalue of an integer type can be converted to a prvalue of another integer type. ... 2 If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source integer (modulo 2 n where n is the number of bits used to represent the unsigned type). [ Note: In a two’s complement representation, this conversion is conceptual and there is no change in the bit pattern (if there is no truncation). — end note ]
Therefore the inverse conversion exists and is the identity as well, this is what should be sanctioned.