1
$\begingroup$

Either in 2's complement form or in 1's complement form?

$\endgroup$

closed as off-topic by Evil, Discrete lizard, Yuval Filmus, David Richerby, vonbrand May 16 '18 at 15:38

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "This question does not appear to be about computer science, within the scope defined in the help center." – Evil, Discrete lizard, Yuval Filmus, vonbrand
If this question can be reworded to fit the rules in the help center, please edit the question.

  • $\begingroup$ 2's complement form $\endgroup$ – kauray May 12 '18 at 15:06
  • 1
    $\begingroup$ C/C++ standard does not specify how to store integers, but for usual implementation, they are stored in 2's complement form. Anyway, language-specific question is off-topic here. $\endgroup$ – xskxzr May 12 '18 at 15:14
  • $\begingroup$ There's also signed-magnitude with a +0 and a -0, and a fourth, weird one. All allowed by the C standard. $\endgroup$ – gnasher729 May 12 '18 at 15:20
  • 2
    $\begingroup$ @gnasher729: The C standard lists only three possible significances for the sign bit, listed in §6.2.6.2¶2. Where did you get a fourth possibility? $\endgroup$ – rici May 12 '18 at 17:41
4
$\begingroup$

Integers

The C and C++ standards do not completely specify how integers are stored in memory. C aimed to be platform-independent and at the time of its creation there were a wide variety of different conventions used. C++, being an extension of C, inherited this behavior.

However, nowadays all systems I am aware of store integers in 2's complement form, where the first bit of each number stores the sign.

Floating-point numbers

The C and C++ standards do not completely specify how floating-point numbers are stored in memory. C aimed to be platform-independent and at the time of its creation there were a wide variety of different conventions used. C++, being an extension of C, inherited this behavior.

However, nowadays all systems I am aware of adhere to the IEEE 754 standard (or possibly some minor variation thereof). In particular, the standard describes a bit layout known as binary32 for 32-bit floating point numbers:

  • The first bit stores the sign.
  • The next eight bits store the exponent $e$ (this can be in the form of either a signed integer or an unsigned but biased integer).
  • The next 23 bits store the mantissa $m$, representing the bits of a number in the range $[0,1)$.

In most cases, this represents the value $m\times 2^e$, though there are many exceptions (such as negative zero, signed infinities, and denormalized numbers).

Floating-point arithmetic is very complicated, and the IEEE 754 standard prescribes the exact value that calculations should return, so processors generally handle it correctly. However, attempting to reach into the guts of a floating point number (e.g. via casting a float* to an char* and then assigning to its referent) is still undefined behavior in C, meaning that compilers can assume valid programs will never do it for optimization purposes.

$\endgroup$
  • 1
    $\begingroup$ The C standard does define how integers are stored, in §6.2.6.2¶2. It leaves the implementation with some options: how many bits, how many unused (padding) bits, and whether the sign bit being one should cause the data bits to be interpreted as being the complement, the inverse, or the absolute value. There is also a specification of the minimum number of meaningful bits (but not the maximum). $\endgroup$ – rici May 12 '18 at 17:46
  • $\begingroup$ Also, you can cast a float* (or any other object pointer type) to char* and examine the values of individual bytes. You can copy the individual bytes and copy them back. What you cannot do is change the values of the individual bytes. $\endgroup$ – rici May 12 '18 at 17:49
  • $\begingroup$ @rici Perhaps it's just me, but that doesn't really sound like "defining how integers are stored". Certainly that wouldn't be enough to confidently do memory hacks that depend on the layout of integers and expect them to be platform-independent. $\endgroup$ – Noncontextual Spelling May 13 '18 at 3:42
  • $\begingroup$ It's not a full definition, to be sure. But neither is it a complete lack of specification, and it is possible to discover quite a bit about the representation. I would certainly not have objected to "do not completely specify how...". It's perhaps also worth noting that the fixed width types intN_t are completely specified, although they are optional. (So they are completely portable between implementations which have them.) $\endgroup$ – rici May 13 '18 at 4:12

Not the answer you're looking for? Browse other questions tagged or ask your own question.