From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25422 invoked by alias); 5 Feb 2002 16:07:27 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 25240 invoked from network); 5 Feb 2002 16:07:25 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 5 Feb 2002 16:07:25 -0000 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16Y87u-0006Yz-00; Tue, 05 Feb 2002 11:07:22 -0500 Date: Tue, 05 Feb 2002 08:07:00 -0000 From: Daniel Jacobowitz To: Klee Dienes Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Function return type checking Message-ID: <20020205110722.A24325@nevyn.them.org> Mail-Followup-To: Klee Dienes , gdb-patches@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i X-SW-Source: 2002-02/txt/msg00116.txt.bz2 On Tue, Feb 05, 2002 at 01:36:41AM -0800, Klee Dienes wrote: > (This is basically the same patch I sent last week, just updated > to the latest source base.) > > The following patch adds "expected return type" support to the target > function call interface. The "expected return type" is specified > using cast syntax; it is ignored if actual type information for the > function is available. If no type information is provided for a > function, the user is now required to provide an expected return type > using the cast syntax, or get an error. Having thought about this since you last posted it, I don't really like it. What you do by overloading the cast syntax for this operation is very ``cute'', but exceedingly unintuitive. > Some examples: > > (gdb) print fabs (3.0) (no type information present) > Unable to call function at 0x%lx: no return type information available. > To call this function anyway, you can cast the return type explicitly > (e.g. 'print (float) fabs (3.0)'). Except for the syntax of the example, I like this message. This is a good message. We need more warnings about doing things like this. Fabs is a bad example, though - can I suggest you look over the list of what GCC defines as builtin functions, and not choose one? > The reason I suggest 2) might be controversial is that the old > behavior can be convenient in the general case. A lot of functions > *do* return int, and when debugging programs without symbols, it can > be annoying to have to declare the return type, just to make the rare > case when functions return floats/structs behave correctly. But I'd > argue that it's not *that* big a deal to cast a return value, and > correctness must always take priority. Losing the implicit int doesn't bother me especially. Have you considered casting the function itself? Something like: (gdb) print ((float (*)(float)) fabs) (3.0) $1 = 3.0 (gdb) set fabs Which, I will note, already works except for the fact that we neglect the argument types on function pointers. Or (gdb) set $fabs = (float (*)(float)) fabs (gdb) p $fabs(4.0) $2 = 4.0 Which works with the same caveat. Specifying just the return type of the function is not useful in the general case. If we do not understand the argument types, it will still crash. I was trying to find an example where float vs. double would cause a problem too, but I can't think of one at the moment. There's one in the testsuite though, for some targets. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer