Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@cygnus.com>
To: Klee Dienes <kdienes@apple.com>
Cc: Daniel Jacobowitz <drow@mvista.com>, gdb-patches@sources.redhat.com
Subject: Re: [RFA] Function return type checking
Date: Sat, 09 Mar 2002 20:30:00 -0000	[thread overview]
Message-ID: <3C8AE16D.9000502@cygnus.com> (raw)
In-Reply-To: <98590BF8-1B4A-11D6-812E-0030653FA4C6@apple.com>

> 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



  parent reply	other threads:[~2002-03-10  4:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-05  1:36 Klee Dienes
2002-02-05  3:24 ` Eli Zaretskii
2002-02-05  8:07 ` Daniel Jacobowitz
2002-02-06 13:43   ` Klee Dienes
2002-02-06 14:14     ` Daniel Jacobowitz
2002-03-09 20:30     ` Andrew Cagney [this message]
2002-03-12  2:38       ` Klee Dienes
2002-03-12  7:56         ` Andrew Cagney
2002-03-12 10:08           ` Klee Dienes
2002-03-12 10:34             ` Andrew Cagney
2002-02-08 13:41 ` Kevin Buettner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3C8AE16D.9000502@cygnus.com \
    --to=ac131313@cygnus.com \
    --cc=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=kdienes@apple.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox