Re: [patch 2/2] Wrap-up expression support for DFP.

Eli Zaretskii
2007-12-21T16:04:21Z

> Date: Thu, 20 Dec 2007 03:49:28 -0200
> From: Thiago Jung Bauermann <bauerman@br.ibm.com>
>
> - doesn't support conversion of 64-bit integers to decimal float,
> because of libdecnumber limitation;
> - error checking in decimal float operations ignore underflow, overflow
> and divide by zero to imitate binary float implementation;

These limitations should be documented in the manual, I think: they
will affect GDB users, right?

> - decimal_from_floating is not very nice because it uses sprintf, but
> I couldn't think of a better way.

Yuck! I don't know anything about libdecnumber, but is there _really_
no other way? What about producing the two parts before and after the
decimal point as integers, then combine them with arithmetic
operations?

> +static void
> +set_decnumber_context (decContext *ctx, int len)
> +{
> + switch (len)
> + {
> + case 4:
> + decContextDefault (ctx, DEC_INIT_DECIMAL32);
> + break;
> + case 8:
> + decContextDefault (ctx, DEC_INIT_DECIMAL64);
> + break;
> + case 16:
> + decContextDefault (ctx, DEC_INIT_DECIMAL128);
> + break;
> + }

I don't think our coding style includes mixed-case symbols. Are these
library functions?

> +void
> +decimal_from_floating (struct value *from, gdb_byte *to, int len)
> +{
> + /* The size of this buffer is a conservative guess: assumes an 128-bit
> + long double could have 40 decimal digits, plus 4 for exponent, plus
> + 3 for mantissa and exponent signs and 'E', plus '\0'. */
> + char buffer[48];

Are the sizes of the exponent, mantissa, etc. available as parameters
from libdecnumber? If so, it would be better to use them explicitly
in allocating buffer[] off the stack (e.g., with alloca). That way,
if your assumptions will ever become incorrect, the code will adapt
automatically.

> + /* We cannot use snprintf here because it is defined only in C99.

We have portable substitutes for snprintf, I think. Take a look at
libiberty, for example.

> + sprintf (buffer, "%Lf", value_as_double (from));

If we must live with going through the printed representation, at the
very least please use "%.30Lf", so as not to lose precision due to the
default number of significant digits produced under "%Lf", arbitrarily
chosen by the libc implementation.

> + /* This is an ugly way to do the conversion, but libdecnumber does
> + not offer a direct way to do it. */
> + decimal_to_string (from, len, buffer);
> + return atof (buffer);

Isn't strtold better here?