From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13270 invoked by alias); 21 Dec 2007 16:04:21 -0000 Received: (qmail 13262 invoked by uid 22791); 21 Dec 2007 16:04:20 -0000 X-Spam-Check-By: sourceware.org Received: from nitzan.inter.net.il (HELO nitzan.inter.net.il) (213.8.233.22) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 21 Dec 2007 16:04:12 +0000 Received: from HOME-C4E4A596F7 (IGLD-84-229-233-247.inter.net.il [84.229.233.247]) by nitzan.inter.net.il (MOS 3.7.3a-GA) with ESMTP id IPQ74906 (AUTH halo1); Fri, 21 Dec 2007 18:01:35 +0200 (IST) Date: Fri, 21 Dec 2007 16:12:00 -0000 Message-Id: From: Eli Zaretskii To: Thiago Jung Bauermann CC: gdb-patches@sourceware.org In-reply-to: <20071220055107.194393592@br.ibm.com> (message from Thiago Jung Bauermann on Thu, 20 Dec 2007 03:49:28 -0200) Subject: Re: [patch 2/2] Wrap-up expression support for DFP. Reply-to: Eli Zaretskii References: <20071220054926.148275471@br.ibm.com> <20071220055107.194393592@br.ibm.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-12/txt/msg00375.txt.bz2 > Date: Thu, 20 Dec 2007 03:49:28 -0200 > From: Thiago Jung Bauermann > > - 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?