From: Klee Dienes <kdienes@apple.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: Klee Dienes <klee@apple.com>, gdb-patches@sources.redhat.com
Subject: Re: [RFA] Function return type checking
Date: Wed, 06 Feb 2002 13:43:00 -0000 [thread overview]
Message-ID: <98590BF8-1B4A-11D6-812E-0030653FA4C6@apple.com> (raw)
In-Reply-To: <20020205110722.A24325@nevyn.them.org>
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
>
> 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
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).
next prev parent reply other threads:[~2002-02-06 21:43 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 [this message]
2002-02-06 14:14 ` Daniel Jacobowitz
2002-03-09 20:30 ` Andrew Cagney
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=98590BF8-1B4A-11D6-812E-0030653FA4C6@apple.com \
--to=kdienes@apple.com \
--cc=drow@mvista.com \
--cc=gdb-patches@sources.redhat.com \
--cc=klee@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