Re: [RFA] Function return type checking

[Andrew Cagney <ac131313 at cygnus dot 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'.

One of the things I've been puzzled by is how a user could get 
themselves in a situtation where the feature was needed.  I was thinking 
that a well written program, having including all relevant headers, 
would have all the relevant information available.

The above is starting to explain why there is a problem.  Can you, humor 
me a little and express it in slightly more concret terms (bits of 
code).  Does C++ have a similar problem?

Keep in mind that Objective C doesn't have the same entrenched 
conventions that normal C suffers from - you've more freedom to define 
its behavour.

> 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.

Andrew