mikeash.com pyblog/friday-qa-2010-01-29-method-replacement-for-fun-and-profit.html comments

Geoff - 2015-07-07 17:57:59

Tue, 07 Jul 2015 17:57:59 GMT

I tried using this technique on a class level method instead of an instance method. In addition to replacing class_getInstanceMethod with class_getClassMethod, I needed to wrap "self" with object_getClass() in the class_replaceMethod() function.



Method origMethod= class_getClassMethod(self, @selector(foo));

class_replaceMethod(object_getClass(self), @selector(foo), (IMP)overrideFoo, method_getTypeEncoding(origMethod));

I'm assuming that is because class_getClassMethod is expecting to be working with Class level methods while class_replaceMethod could work with either. Is this correct?

Steven - 2014-04-16 10:26:27

Wed, 16 Apr 2014 10:26:27 GMT

Mike, class_replaceMethod does not return the imp of the superclass method. If the method was newly added to the class, gOrigDrawRect is 0.

In that case, I add an extra method_getImplementation, using the method I get from class_getInstanceMethod. That should return the nearest superclass IMP of the method.

mikeash - 2013-09-27 14:33:04

Fri, 27 Sep 2013 14:33:04 GMT

Actually, in C, a pointer is definitely not a pointer. There is no guarantee that pointers of different types have the same internal representation. This is especially true for function pointers. What you say happens to be the case on popular architectures we use today, but it's not part of C.

In any case, the type gets converted, even if the value remains the same.

martin - 2013-09-15 12:25:45

Sun, 15 Sep 2013 12:25:45 GMT

you wrote "and thanks to the magic of C, the void * gets implicitly converted to the right pointer type anyway.)"

i'm sure you are aware that nothing get's "converted" here, in C a pointer is a pointer, 4 or 8 bytes are copied, that's all.

(not to be confused by the real magic Objective C can do converting types on the fly when setting them, setting a BOOL or float from a NSNumber for example, using setValueForKey.

mikeash - 2013-08-20 13:38:33

Tue, 20 Aug 2013 13:38:33 GMT

If you call through to the original implementation first, you can the retrieve the copied string from the regular pasteboard.

chandan - 2013-08-20 10:33:03

Tue, 20 Aug 2013 10:33:03 GMT

I am swizzling Copy: and Paste: method of UIResponder. I have to write the copied content to a private pasteboard.

- (void)copyToPrivatePasteboard:(id)sender
{
UIPasteboard *privatePasteboard = [self getPrivatePasteboard];
[privatePasteboard setString:@""];//How to get the copied string to store in pasteboard.
}

How can i write copied string to pasteboard. The parameter i am getting is of type id. If i convert it to NSString, it won't be proper because it is the sender who is calling this method (UIMenuController).

Whitney Young - 2013-02-18 18:43:47

Mon, 18 Feb 2013 18:43:47 GMT

I just came back to this, and was re-reading some of the comments. Mike, your comment from 2010-01-29 doesn't seem quite right. The class_replaceMethod returns NULL if the method was added rather than replaced. I think the simplified version would be:



Method origMethod = class_getInstanceMethod(self, @selector(drawRect:));

gOrigDrawRect = (void *)method_getImplementation(origMethod);

class_replaceMethod(self, @selector(drawRect:), (IMP)OverrideDrawRect, method_getTypeEncoding(origMethod))

Dmytro - 2012-11-16 22:06:55

Fri, 16 Nov 2012 22:06:55 GMT

Can I replace class method (declared as + (void) methodname ....) ? I successfully replace instance method ( -(void) methodname ...), but can't class method...

Bernhard - 2012-10-18 17:46:26

Thu, 18 Oct 2012 17:46:26 GMT

Thank you, Mike, for this great article!

I think, though, that you should have mentioned that in order to use the class_...() and method_...() functions, one needs to include the libobjc.A.dylib library in the Xcode Target and then #import <objc/runtime.h> in the source file.

mikeash - 2011-05-19 22:44:22

Thu, 19 May 2011 22:44:22 GMT

class_getInstanceMethod will return the superclass's implementation if the class in question doesn't have one of its own, so everything still works as desired.

Ling Wang - 2011-05-19 05:37:49

Thu, 19 May 2011 05:37:49 GMT

In MethodSwizzle, what if overrideSEL is not implemented in the class in question, but rather in a superclass?

mikeash - 2010-08-14 15:36:10

Sat, 14 Aug 2010 15:36:10 GMT

That's an interesting case that I hadn't thought of. Thanks for pointing it out.

Ryan Petrich - 2010-08-14 05:23:26

Sat, 14 Aug 2010 05:23:26 GMT

Your "Direct Override" method fails to handle the case where two hooks are applied to the same method: first on a descendent class that does not override the method and again on the super class.

Example: Application has classes Dog and Mammal. Mammal has a reproduceWith: method. MadScientist uses your Direct Override technique to hook -[Dog reproduceWith:] and inject his additional code. EvilGeneticist uses any other hook technique to hook -[Mammal reproduceWith:].
Later, -[Dog reproduceWith:] is called; only MadScientist's hook is runs instead of both MadScientist and EvilGeneticist's hooks.

This is not a theoretical problem--the iPhone jailbreak community has encountered this issue numerous times and has standardized on two libraries: MobileSubstrate emits ARM bytecode at runtime to avoid it, and CaptainHook avoids it through macro trickery.

None - 2010-05-18 10:38:35

Tue, 18 May 2010 10:38:35 GMT

Hi, i have some questions about doing the swizzle on some application's class method when under 64bit.

in 32bit, the code will run as i expected, but when in 64bit, i get this error:

Error loading XXX: dlopen(XXX, 123): Symbol not found: _OBJC_CLASS_$_SomeClass
Referenced from: XXX
Expected in: flat namespace
in XXX

i googled for solutions, and i get some answers like:

http://groups.google.com/group/f-script/browse_thread/thread/09f07a3771032de4

i go and see the code, which does not fix the error.

i use JRSwizzle's + (BOOL)jr_swizzleClassMethod:(SEL)origSel_ withClassMethod:(SEL)altSel_ error:(NSError**)error_

thx :)

mikeash - 2010-02-10 01:35:07

Wed, 10 Feb 2010 01:35:07 GMT

My test program has a bug in it: in main, y should be of type char. Still fails as described with that change made.

I forgot to mention: even if none of your parameters are of the offending types, there's still nothing which guarantees that the calling conventions will match between a vararg call with certain argument types and a non-vararg receiver with those same types. It's far more likely to work (and I think the ABIs of the platforms that OS X runs on may guarantee it on those particular platforms) but still unsafe.

mikeash - 2010-02-10 01:13:19

Wed, 10 Feb 2010 01:13:19 GMT

It gets worse. Because of C's type promotion rules, you can't pass float, short, or char (or the unsigned counterparts of the last two) through a vararg function, because they get promoted to double and int. This code illustrates the problem:

void Tester(int ign, float x, char y)

{

    printf("float: %f  char: %d\n", x, y);

}



int main(int argc, char **argv)

{

    float x = 42;

    float y = 42;

    Tester(0, x, y);

    

    void (*TesterAlt)(int, ...) = (void *)Tester;

    TesterAlt(0, x, y);

    

    return 0;

}

On my computer, the second invocation prints float: 0.000000 char: 0.

objc_msgSend doesn't use vararg calling conventions. The convention it "uses" is any convention which is compatible with a pointer return value, and placing the first two arguments in a place where they can be expected. objc_msgSend completely ignores all remaining arguments, and lets them pass through unhindered. The caller and the eventual callee (after objc_msgSend looks it up and jumps to it) still have to agree on how those work, and if the caller thinks they're varargs and the callee doesn't, they won't get along.

You must cast all calls to objc_msgSend and its variants in order to have the compiler generate the correct code. Failing to do so will work for many cases, but only because you're getting lucky. The same goes for casting IMPs.

Matt Gallagher - 2010-02-10 00:06:59

Wed, 10 Feb 2010 00:06:59 GMT

Okay, I was overlooking the fact that the declaration of IMP actually declares the third parameter to be a "...". You are correct; I retract my point about not using varargs.

However, this is the calling convention used by objc_msgSend, and by extension all methods except the objc_msgSend_(st/fp/fp2)ret methods. But yes, (st/fp/fp2)ret methods require a correct cast of the IMP or other special handling to work. Fortunately, the compiler is smart enough to give a hard error if you try to do this without a cast -- it doesn't slip through unnoticed.

I find the bigger problem is that without a signature, all regular parameters need to be correctly typed or they won't be passed correctly (since the compiler can infer the wrong register or stack size). This can cause problems without so much as a warning if you're not careful.

mikeash - 2010-02-09 17:54:41

Tue, 09 Feb 2010 17:54:41 GMT

By the way, lest this objection seem too theoretical, consider what happens if you use that macro for a method which returns a struct.

mikeash - 2010-02-09 17:46:01

Tue, 09 Feb 2010 17:46:01 GMT

No need to leave, I welcome all reasonable discussion.

Your macro looks like this:

#define invokeSupersequent(...) \

    ([self getImplementationOf:_cmd \

        after:impOfCallingMethod(self, _cmd)]) \

            (self, _cmd, ##__VA_ARGS__)

-getImplementationOf: is defined to return an IMP, which takes variable arguments after the self and _cmd parameters. This macro does not cast the IMP to a different function pointer type (and indeed could not, as it doesn't have enough information to do so). This means that the IMP is being called with variable argument calling conventions. Or did I miss some place where everything gets cast to the right function pointer type before calling?

Matt Gallagher - 2010-02-09 13:01:14

Tue, 09 Feb 2010 13:01:14 GMT

On the point of vararg method calling conventions though... the supersequent code doesn't actually use them. The macro is variable argument but is expanded to a non-vararg parameter list by the preprocessor. The ObjC compiler sees (and compiles) regular parameters only.

Sorry to have gotten in the way. I'll see myself out...

Matt Gallagher - 2010-02-09 12:47:48

Tue, 09 Feb 2010 12:47:48 GMT

'fraidy cat :-)

But yes, the supersequent method stuff is a hack for the same reason any "undocumented" stuff is: it can be gone at a moment's notice. It relies on the way that things just happen to be done.

As for multiple categories though... the way the ObjC 1.0/2.0 runtimes just happen to be written, all categories are preserved in the order that they are loaded. Technically load order is deterministic but it's fragile -- generally, the system libraries will be loaded before your code, but not always.

But don't ship code with it unless you want to get burned.

mikeash - 2010-02-01 18:40:11

Mon, 01 Feb 2010 18:40:11 GMT

Extreme hacking, and not the good kind. The technique as a whole relies on the runtime keeping the old IMP in the class method list after adding a category. As far as I know, this behavior is not guaranteed. This also won't chain: if you have two or more methods all implemented in a category (one of these could be in Apple's code, beyond your control) then it's still not guaranteed who "wins". There's also a big problem with the macro itself, in that it assumes the method signature is compatible with vararg calling conventions, something that's not at all guaranteed. Gallagher doesn't mention any of these caveats, which worries me greatly. He says that this technique is mainly good for debugging because it's slow. I say that it's only good for debugging because you don't have any guarantees that it'll actually work.

Cédric Luthi - 2010-02-01 09:21:11

Mon, 01 Feb 2010 09:21:11 GMT

Actually, it is technically possible to call the original implementation of a method overridden in a category. Matt Gallagher explains how in his Supersequent implementation blog post: http://cocoawithlove.com/2008/03/supersequent-implementation.html

Warning: extreme hacking inside!

mikeash - 2010-01-29 22:24:08

Fri, 29 Jan 2010 22:24:08 GMT

I'd always pondered the potential trouble of giving the original method the wrong _cmd, but never came across a place where it mattered in practice. Interesting!

Whitney Young - 2010-01-29 21:00:59

Fri, 29 Jan 2010 21:00:59 GMT

One interesting place that I've seen method swizzling fail is with the following NSResponder methods:



mouseEntered:

mouseExited:

mouseMoved:

If I remember correctly, these methods all use an IMP that actually determines what to do based on the _cmd argument. Therefore, when you swizzle, you end up passing override_mouseEntered: as _cmd instead of a value that it knows how to handle.

The direct override should not suffer from this problem since it's passing on _cmd correctly.

mikeash - 2010-01-29 20:36:08

Fri, 29 Jan 2010 20:36:08 GMT

Oh nice, I completely missed that aspect of that function, and that it returns the old implementation. So the Direct Override's +load method can be cut down to just this:

Method origMethod = class_getInstanceMethod(self, @selector(drawRect:));

gOrigDrawRect = (void *)class_replaceMethod(self, @selector(drawRect:), (IMP)OverrideDrawRect, method_getTypeEncoding(origMethod))

Remy Demarest (Psy|) - 2010-01-29 20:11:43

Fri, 29 Jan 2010 20:11:43 GMT

It's not needed to make two separate codes for when the method is implemented in the class or when it's only implemented in the super-class.
The runtime-function class_replaceMethod() takes care of that, if the method is defined in the class, then the replacement is done, if it's defined in a super-class then the function adds the method to the class. So you simply need to retrieve the "old" implementation (that might be the super-class's implementation) and call it in your function replacement.

Joel Bernstein - 2010-01-29 19:43:25

Fri, 29 Jan 2010 19:43:25 GMT

If you're going to use method 2, you could do a lot worse than using Jonathan Rentzsch's JRSwizzle class:

http://github.com/rentzsch/jrswizzle

It takes care of most of the mindless busywork and edge cases.