From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1798 invoked by alias); 10 Mar 2002 04:30:41 -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 1705 invoked from network); 10 Mar 2002 04:30:38 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.135.44) by sources.redhat.com with SMTP; 10 Mar 2002 04:30:38 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id A25303E0B; Sat, 9 Mar 2002 23:30:37 -0500 (EST) Message-ID: <3C8AE16D.9000502@cygnus.com> Date: Sat, 09 Mar 2002 20:30:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.8) Gecko/20020210 X-Accept-Language: en-us MIME-Version: 1.0 To: Klee Dienes Cc: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: [RFA] Function return type checking References: <98590BF8-1B4A-11D6-812E-0030653FA4C6@apple.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-03/txt/msg00130.txt.bz2 > On Tuesday, February 5, 2002, at 08:07 AM, Daniel Jacobowitz wrote: > > Have you considered casting the function itself? Something like: > (gdb) print ((float (*)(float)) fabs) (3.0) > $1 = 3.0 > (gdb) set fabs Only: print ((float(*)()) fabs) (3.0) should be necessary. GDB will then attempt to pass the arguments according to GDB's interpretation of traditional K&R parameter passing rules. > We have; for a long time that was the answer we gave to people who were running into this problem. Our experience was that it was a nightmare to explain to people how this mechanism worked, and that even for folks who did undertand it, they found it a major mental burden to use in practice. C function casting syntax is neither intuitive nor pleasant to type. > > The reason we chose the "cast" syntax wasn't so much to be cute, but because it was the first thing everyone tried when they were trying to get this to work. People would try 'print (float) fabs (3.0)', followed by 'print {float} fabs (3.0)', usually followed by several unsuccessful attemtps to remember the correct syntax to cast the function pointer. > > I also think there's a pretty solid rationale behind the syntax, and one that generalizes to argument-passing. The theory goes: > > All symbols without debugging information are assumed to be of type 'unknown' (previously, they were assumed to be 'int', or (int (*) ())). When you cast an expression of type 'unknown' to anything else, GDB does no conversion, but simply interprets the data (or generates the data) according to the specified type. So if you have 'f' with no symbols, > > print (long long) f ((long long) 7, (float) 3.0) > > will generate a function call as if 'f' had been declared as > > long long f (long long, float) > > For function arguments, I claim this is both intuitive and matches the behavior of the C compiler. For function return values, wee have to choose something for what 'print (type) f ()' is to mean, and I claim that it's the best of the two alternatives (the other being "assume 'int', then cast the 'int' to the specified type). I've personally got reservations over introducing a change that, given a file like: void b(void) { double d; d = (double) bar ((float) 3); } radically alters gdb's behavour given: print (double) bar((float) 3) and rejects (?) print bar((float) 3) However, I do see your point that even calling bar() (when bar() has no debug info) is dangerous. Is this feature intended for C or ObjectiveC developers? Andrew