Why doesn't float overflow?

Question

C++ / C#

#define _CRT_SECURE_NO_WARNINGS

#include <stdio.h>
#include <conio.h>
#include <float.h>

int main(void)
{
  float value = FLT_MAX * 1.0000001f; // FLT_MAX + 1.0f

  printf("%e", value);

  _getch();

  return 0;
}

Why, taking the maximum value of the float type and multiplying it, for example, by 1.0000001, we get infinity, and if we add 1.0f (or some value) to this (like the maximum) number, then the maximum value (3.402823e + 38) is still displayed, but not infinity?
The value seems to be the maximum, and adding a small * number to it turns out to be more than the maximum. And if you multiply by a number, then you get an overflow and inf is displayed. Explain why this is so, multiplication overflows, and addition seems to simply cut off extra bits. (The only guess is the internal storage of the real number)

Answer 1

The magic of floating points :)
Numbers should be approximately the same order, otherwise UB (with reservations).
3.4e38 + 1.0 = 3.4e38. This is equivalent to 3.4e38 + 0.0, because 1 compared to 1e38 is zero.
And when multiplying, the difference will be already in the 7th decimal place, which float can detect and report overflow (+INF).

Answer 2

Explain why this is so, multiplication overflows, and addition seems to simply cut off extra bits.

Because that's exactly what it is: for addition, numbers are reduced to the same order. FLT_MAX order is 2^127, 1.0 order is 2^0. Those. one is shifted 127 bits to the right before being added to FLT_MAX. None of the standard representations of floating point numbers provides for so many digits, extra digits are cut off, one turns into 0.
The minimum number that can be added to FLT_MAX and get infinity is 2 ^ (127 - 24). When this number is normalized with FLT_MAX, one is obtained shifted to the right by 24 bits, just to the last significant bit of the float mantissa.

Answer 3

Imagine we have decimal arithmetic with three significant digits. Accordingly, addition works with no more than five digits: three actually significant ones, on the left for carry and on the right for rounding. What happened, in any case, will be rounded up to three.

 99900000000000
+             1,00
 -----------------
 9990   →   9,99e13

If we make the second term larger, then it will be

 99900000000000
+   50000000000
 -----------------
 9995   →   1,00e14 → переполнение

That is, here's what needs to be added for an overflow to occur: depending on the settings of the coprocessor, either ulp(FLT_MAX) (ULP = Unit of Last Place - the price of the least significant digit in this order), or ulp(FLT_MAX)/2.