From: Klee Dienes <kdienes@apple.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Klee Dienes <klee@apple.com>, Daniel Jacobowitz <drow@mvista.com>,
gdb-patches@sources.redhat.com
Subject: Re: [RFA] Function return type checking
Date: Tue, 12 Mar 2002 10:08:00 -0000 [thread overview]
Message-ID: <0A63ABF3-35E4-11D6-A901-0030653FA4C6@apple.com> (raw)
In-Reply-To: <3C8E250C.4070601@cygnus.com>
Saying that I "need" the infrastructure change for Objective-C would
probably be a bit strong.
The basic issue arises when evaluating Objective-C expressions like the
following:
call [[window boundingBox] print]
Here 'window' is of type NSWindow, an opaque type defined in a system
library, and 'boundingBox' is a method of NSWindow that returns a
NSRect. The issue arises because '[window boundingBox]' is really a
function call to 'objc_msgSend_stret (window, selector)'. There
generally isn't symbol information available for 'objc_msgSend_stret',
but there often is for '[NSWindow boundingBox]'. So it's nice for
Objective-C to be able to pass the correct return type information to
'call_function_by_hand' so that the result returns with the correct
type, rather than have to cons up a fake function value with fake return
type to pass to 'call_function_by_hand'.
On Tuesday, March 12, 2002, at 07:55 AM, Andrew Cagney wrote:
> So there are two reasons for the change? The infrastructure you need
> for objective C and a user visible interface change. Can you expand a
> little on the objective C problems. If objective C has good reason for
> this infrastructure than I can't see why that part shouldn't go in.
next prev parent reply other threads:[~2002-03-12 18:08 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
2002-03-12 2:38 ` Klee Dienes
2002-03-12 7:56 ` Andrew Cagney
2002-03-12 10:08 ` Klee Dienes [this message]
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=0A63ABF3-35E4-11D6-A901-0030653FA4C6@apple.com \
--to=kdienes@apple.com \
--cc=ac131313@cygnus.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