From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 565 invoked by alias); 22 Jan 2006 20:33:28 -0000 Received: (qmail 556 invoked by uid 22791); 22 Jan 2006 20:33:28 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sun, 22 Jan 2006 20:33:27 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1F0ltr-0007c7-Uh; Sun, 22 Jan 2006 15:33:24 -0500 Date: Sun, 22 Jan 2006 20:33:00 -0000 From: Daniel Jacobowitz To: Alexandre Oliva Cc: Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: fixes for type-punning warnings in GCC 4.1 Message-ID: <20060122203323.GC27224@nevyn.them.org> Mail-Followup-To: Alexandre Oliva , Eli Zaretskii , gdb-patches@sources.redhat.com References: <20051219221830.GA32448@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00305.txt.bz2 On Mon, Jan 16, 2006 at 04:26:57PM -0200, Alexandre Oliva wrote: > On Dec 19, 2005, Daniel Jacobowitz wrote: > > >> > From: Alexandre Oliva > >> > Date: Mon, 19 Dec 2005 17:20:48 -0200 > > >> > - num = sscanf (p, "%g%s", (float *) &putithere->typed_val_float.dval,s); > >> > + num = sscanf (p, "%g%s", (float *) (void *) &putithere->typed_val_float.dval,s); > > > We should fix it properly, in any case. The right solution here is > > pretty apparent: delete the "float" case, and #define appropriate > > format characters for DOUBLEST in doublest.h, in the same place we > > typedef DOUBLEST. Just like GCC's HOST_WIDE_INT_PRINT. > > We can't quite do that because we may have to issue more complex > command patterns than simply a plain sscanf into the output location. > I've come up with this macro that defers to a static inline function > in the complex case. Is this change acceptable? Tested on > amd64-linux-gnu. > > Another alternative that I found uglier would be to define a > DOUBLEST_SCAN macro and a DOUBLEST_SCAN_TYPE typedef, and always > declare a variable of DOUBLEST_SCAN_TYPE, scan into it, and then copy > the scanned value to the given output variable. This enables people > to construct more complex scan patterns, but is it worth the ugliness > and extra copying for the sake of the uncommon `has long double but > can't scanf it' case? The output is always a DOUBLEST. I don't know of any reason why we should enable HAVE_LONG_DOUBLE if we can't printf and scanf them; would this be simpler in that case? Don't make DOUBLEST something we can't scan or print. -- Daniel Jacobowitz CodeSourcery