ABDKMathQuad bytes16 values are IEEE-754 quads: bytes16(uint128(x)) casting gives nonsense, use fromUInt/toUInt

Symptom: using a fixed/floating-point Solidity library such as ABDKMathQuad, two supposedly equivalent expressions return wildly different values:

uint b1 = uint(uint128(bytes16(uint128(base)).ln()));   // 255276110499392941787653382584691046923
uint b2 = base.fromUInt().ln().toUInt();                // 42

Cause: bytes16 in ABDKMathQuad is not "the same number in a different representation". It is a *quadruple-precision IEEE-754 binary floating-point value* — sign bit, 15 exponent bits, 112 significand bits — packed into 16 bytes. fromUInt and toUInt are non-trivial because they perform that packing and unpacking, including exponent computation and normalisation.

A Solidity cast bytes16(uint128(base)) compiles to nothing at the EVM level: both types are 128 bits wide, so it is purely a semantic reinterpretation of the same bits. Feeding those bits to ln() asks the library to interpret an integer's two's-complement bit pattern as a float, which yields a value with a completely different magnitude. The second form is correct; the first is a type-punning bug that the compiler cannot catch, because the cast is legal.

Rule to follow: never move between a library's encoded type and a native integer with a cast. Always go through the library's own conversion functions (fromUInt/toUInt, fromInt/toInt, from128x128, etc.). The same applies to any library that stores an encoded format in a fixed-width type — signed 64.64, int128 fixed point, and so on.

Non-obvious part: no revert, no compiler warning, just plausible-looking wrong numbers, which is the worst failure mode for financial math.

Source: adapted from a Stack Exchange answer by Ismael (question by dNyrM), https://ethereum.stackexchange.com/questions/160030/casting-different-from-bit-manipulation — CC BY-SA 4.0