GeezerVison

…rmat

DecimalCodec.EncodeDecimal wrote coefficients with more digits than the
format allows, and exponents outside its range, without any check (only a
Debug.Assert). In Release builds the excess bits overflowed into the
combination/exponent fields and the server stored a different value, e.g.:

  12345678901234567890123456789012345 -> DECFLOAT(34) stored 8345678901234567890123456789012345
  30000000000000004E-17               -> DECFLOAT(16) stored 0.08000000000000004
  1E400                               -> DECFLOAT(16) stored 8.000000000000001E-353

The encoder now brings the value into the format's ranges without changing
its numeric value (dropping trailing zeros of the coefficient, folding the
exponent into the coefficient, clamping the exponent of zero), and throws
OverflowException when the value cannot be represented exactly (too many
significant digits, exponent overflow or underflow). Values that previously
got corrupted although representable (e.g. 1E384 in DECFLOAT(16)) now work.

The conversions formatted the value with a fixed custom format and then
removed the decimal point, assuming one was present. This threw
ArgumentOutOfRangeException for every value without a fractional part,
e.g. (FbDecFloat)1m, (FbDecFloat)100m, (FbDecFloat)2.0, and for values
smaller than the format's decimal places, e.g. (FbDecFloat)1e-20. It also
dropped the scale of decimals (1.10m became 1.1) and digits beyond 15
decimal places of doubles (7 for floats).

- decimal: converted exactly from its 96-bit integer and scale, so the
  value and its scale are preserved (1.10m -> 110E-2), including -0.
- double/float: converted to the shortest decimal that round-trips to the
  same binary value ("R" format), e.g. 0.1 -> 1E-1, 0.1 + 0.2 ->
  30000000000000004E-17, 1e-20 -> 1E-20; -0.0 -> negative zero.

A converted double may have up to 17 significant digits; sending it to a
DECFLOAT(16) throws OverflowException instead of being silently rounded
(this relies on the encoder range check of the previous commit).

Random.NextInt64() never returns a negative value, so the random doubles
were all positive. Use the full long range and assert both signs are covered.

Parameters: a DECFLOAT parameter only accepted FbDecFloat; any other value
(decimal, double, int, ...) threw InvalidCastException, even when the
parameter was created by AddWithValue with a decimal. Values of type
decimal, double, float, the integral types and BigInteger are now converted
to FbDecFloat (decimal exactly, double/float to the shortest round-trip
value). A value that does not fit the DECFLOAT precision exactly throws
OverflowException instead of being rounded.

Reader: GetDecimal, GetDouble, GetFloat, GetInt16/32/64 and GetByte (and
the matching GetFieldValue<T>) on a DECFLOAT column threw
InvalidCastException because FbDecFloat is not IConvertible. Now:

- GetDecimal: exact, keeping the scale (1.10 -> 1.10m); OverflowException
  when the value cannot be represented exactly (too large, too many digits,
  NaN, infinity).
- GetDouble/GetFloat: nearest value, like on NUMERIC columns; NaN and
  infinities are mapped, out-of-range values become infinity or zero.
- Integer getters: nearest integer, ties to even, as Convert does for
  decimal columns; OverflowException when out of range, NaN or infinity.

FbDecFloat gets the matching public explicit conversions to decimal, double
and float.