Re: NIB loader: custom views don't draw themselves

[Luboš Doležel]

On 08/09/2013 12:30 PM, David Chisnall wrote:
> On 9 Aug 2013, at 11:18, Luboš Doležel <address@hidden> wrote:
> 
>> Which is quite interesting, because I never stated that "obj" is of
>> type NSView*, it is still just "id". Is it legal for compiler to
>> assume that?
> 
> The compiler has to know the types of the arguments to be able to
> create the call frame correctly.  If the call frame is for
> -initWithRect:(int) and the method is initWithRect:(NSRect) then the
> callee will, depending on the architecture's ABI) expect the register
> that you've just stored 0 in to contain a pointer to an NSRect
> allocated somewhere on the stack (and so segfault when it tries to
> load it) or expect the four words above the call frame to contain an
> NSRect (and expect to be able to store here, so potentially overwrite
> some things on the stack, including the return address and so give a
> bug that can be an exploitable vulnerability).

That's absolutely clear. The point was only to see which method gets
invoked.

> It is undefined behaviour to call a method with the wrong signature.
> It is also undefined behaviour to override a method and give it a
> different signature.
> 
> The GNUstep runtime will call any method with a matching type or
> raise an error if there isn't one.  The Apple runtime will silently
> corrupt the stack.  I consider our behaviour to be better.
> 
> If you have code that depends on undefined and dangerous behaviour,
> then the correct thing to do is fix the code.

The question is how?

Signature of initWithFrame: (NSRect) with GNUstep is: @address@hidden:8
With Apple's AppKit, it is: @address@hidden:8{CGRect={CGPoint=dd}{CGSize=dd}}16

While they seem vastly different, sizeof(NSRect) on both platforms is
32. I'd assume that they are compatible.

-- 
Luboš Doležel