On 9 Aug 2013, at 11:18, Luboš Doležel <[email protected]> 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 _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
