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

[David Chisnall]

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

> And once I correct the compile error and supply a NSRect() in arguments,
> then things break and initWithFrame: in class "c" is not invoked any
> more. initWithFrame: in super class (NSView) is invoked instead.
> 
> I assume that this has something to do with typed selectors, since the
> type info used for initWithFrame: in the subclass is different.
> 
> But is this behavior correct? I assumed that type information was only
> supposed to be used for runtime checks (warnings) and shouldn't affect
> where the message gets delivered.

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.

David

-- Sent from my brain