I'd like to use a custom malloc and free for some allocations in an iOS app, including those made by classes like NSMutableData.
Is this possible?
If so, how do I do it?
What I'd actually like to do is zero out certain data after I've used it, in order to guarantee forward security (in case the device is lost or stolen) as much as possible. If there's an easier way to do this that doesn't involve replacing malloc then that's great.
I believe I need to replace malloc in order to do this because the sensitive data is stored in the keychain --- and I have no option other than to use NSDictionary, NSString and NSData in order to access this data (I can't even use the mutable versions).
Instead of overwriting generic memory management functions you can use custom allocators on the sensitive objects.
The keychain services API is written in C and uses Core Foundation objects, like CFDictionary, CFData and CFString. While it's true that these objects are "toll free" bridged to their Objective-C counterparts and are usually interchangeable they have some abilities not available from Objective-C. One of these features is using custom allocators.
CFDictionaryCreate for example takes an argument of type CFAllocatorRef which, in turn, can be created using CFAllocatorCreate. The allocator holds pointers to functions for allocation and deallocation, among others. You can use custom functions to overwrite the sensible data.
Why do you need to go so low-level about it? I'd just overwrite the data in the NSMutableData instance with zeroes instead. If you really need to mess with malloc - I'd probably write a category on NSObject and override the memory-handling functions.
Disclaimer: I have no iOS experience, but I understand that it uses GCC. Assuming that is correct...
I have done this, albeit with GCC on the PlayStation3. I don't know how much of this is transferable to your case. I used the GCC objcopy utility with --weaken-symbol. (You may need to use nm to list the symbols in your library.
Once you've "weakened" the library's malloc, you just write your own, which is then used instead of the original when linked (rather than giving you a link error). To delegate to the original you may have to give it another name somehow (can't remember -- presumably doable with one of the binutils or else there's both a malloc and a _malloc in the library -- sorry, it's been a while.)
Hope that helps.
I'd encourage you to use the Objective-C memory management system based on ownership (retain/release). Memory Management Programming Guide
Another option would be to use C structures with C memory management rules like malloc.
NSMutableData methods like dataWithBytes:length use calloc / bzero internally already. Is that good enough for you?
Related
I'm reading a book on Objective C, and I was wondering about 2 things:
1.Should I take the time currently to read a whole chapter on memory management since we mostly use ARC?(only asking this question to make sure im managing time properly)
2.If you are doing a really good job on manual management, can you get to better performance than using ARC? (like that your app will work faster)
tnx
You should at least familiarize yourself with the basic concepts of the manual memory management, because ARC uses it under the hood. You need to learn at least about three things: retain, release, and autorelease. This will help you understand discussions about ARC's inner working.
ARC is mostly a compiler trick (with some support from the runtime). You can write less code, but you cannot get better performance from it. Essentially, ARC lets you deal with memory management declaratively, while the manual management uses imperative style. However, both systems call the same methods from the runtime.
1、Of course you should.ARC is based on the same memory management,just let the compiler do the same work.If you want to master a kind of technology，try to know how does it work is a faster way.
2、Actually,they do the same performance.Just let the compiler do what did you do before.For when you retain an object(which is a property) in the class, we always release in the dealloc.you alloc an object in a method,assign to local pointer,it will be release when the stack memory of this method clean up;if you retain it in the method to the method's local variable you release it in the same place.Then you will be find they are all predictable.why not let the machine do it?
I'm starting a multiplayer game, but the examples show passing a NSData object that was created using a structure. With ARC though, I can't use C structures. (correct?) It seems that I'm supposed to use objects instead of C structures using ARC. But how do I send NSData packets of objects?
I guess I could hard code a big byte array, but it seems like there should be an easier way.
Also, if it is possible to send an object, how do I send multiple objects and be able to differentiate between the ones I send?
Thanks!
ARC does not block you from using C structures, you just need to work a bit around the auto deallocation.
Also, if you want the quick and dirty way of handling it, you could disable ARC on your multiplayer manager, using this method.
Please describe which code you are following, and which ones are giving you problems.
The answer to my question was to use a NSKeyedArchiver. It allows one to pack an object (or anything) into a NSData object.
Right so I have noticed that you can do NSClassFromString and NSSelectorFromString.
Is it possible to do something like NSVariableFromString?
No. Compiled applications don't contain variable names except when debug info is included and it usually isn't for release applications.
The objective C runtime has lots of goodies for your consumption.
If you want an iVar, you can call object_getInstanceVariable with a string name.
If you want variables, it's a bit more work, and they have to be globally visible to the linker. You can use CFBundleGetDataPointerForName for that purpose.
Be sure to read the documentation for restrictions and specific information about runtime information, and the availability of stuff on different platforms.
You can get values from strings using NSScanner but, as JemeryP notes, at runtime variable names have generally been converted to pointers and memory addresses.
I found an implementation of a priority queue that primarily uses CFBinaryHeap to work.
I'm currently using the -fno-objc-arc compiler flag to skip the usage of ARC while compiling these files. I attempted to update this code to take advantage of ARC, though I've run into a few snags of understanding.
Is there anyone here who has updated code similar to this for use with ARC?
How do you handle things like free(), and CFRelease()? Can we just get rid of them?
What do you do with the retain and release methods you create for CFBinaryHeapCallBacks?
Do you use __bride or __bridge_transfer to reference the const void * into Objective-C objects? Likewise should you use (__bridge_retained void *) or obj_unretainedPointer() to do the reverse?
ARC basically is a compiler technology that automatically inserts calls to -retain, -release, and -autorelease as needed. It does not remove the need for retains and releases, it just makes them automatic (in the process, optimizing out many that are not required, and playing other tricks to make various common patterns much more efficient than if you did it by hand).
ARC knows nothing about Core Foundation, nor about void* objects, malloc, free, or anything other than ObjC memory management.
This means that as long as you use Core Foundation objects, you should continue to use CFRelease. And if you malloc memory, you should continue to free it.
But.... what if you want to take memory that was created by Core Foundation and transfer it to Cocoa via a toll-free bridge? That's where __bridge* comes in. One of the best sources of information is the clang docs themselves. A great blog article is Everything you need to know about ARC. It includes many useful links to the definitive information.
But here's the short answer (from Transitioning to ARC)
NSString *c = (__bridge_transfer NSString*)my_cfref; // -1 on the CFRef
CFStringRef d = (__bridge_retained CFStringRef)my_id; // returned CFRef is +1
Using __bridge_transfer logically moves a CF object into Cocoa. Using __bridge_retained logically moves a Cocoa object into CF. You use these when you are really transferring ownership of the object. In the above example, you generally shouldn't continue using the my_ variables in my opinion. These are particularly useful in cases where you are returning the result out of the function. These should be used for their logical ownership functionality only. Don't use them as a way to "fake" a manual call to retain or release.
If you just want to have a temporary "bridged" pointer to the object so you can use it in CF or Cocoa without transferring it, then use __bridge. That's a no-op that says "don't do any memory management, just let me pretend for the moment that it's the other kind of object." If you do a lot of toll-free bridging, you'll wind up using __bridge quite a lot (making it seem like a small toll.... :D)
Here is a pure objective-c implementation of PriorityQueue, that supports ARC:
https://github.com/jessedc/JCPriorityQueue/tree/experimental/heap-queue
Is simple to implement non ARC lib into XCode project. Just open "Build Phases"(menu when click on your project target) -> "Compile Sources" and to files, which are not using ARC add by double click flag "-fno-objc-arc" and your're done. So simple :)
I'm starting to code in objective-c and I've just realized that objects can only be passed by reference.
What if I need an object to use static memory by default and to be copied instead of referenced?
For example, I have an object Color with 3 int components r, g and b. I dont want these objects to be in dynamic memory and referenced when passing to functions, I want them immutable and to be copied like an int or a float.
I know I can use a c struct, but I also need the object Color to have methods that gets/sets lightness, hue, saturation, etc. I want my code to be object oriented.
Is there any solution to this?
EDIT: If for example I'm building a 3d game engine, where I'll have classes like Vector2, Vector3, Matrix, Ray, Color, etc: 1) I need them to be mutable. 2) The size of the objects is roughly the same size of a pointer, so why would I be copying pointers when I can copy the object? It would be simpler, more efficient, and I wouldnt need to manage memory, specially on methods that returns colors. And In the case of a game engine, efficiency is critical.
So, if there is no solution to this... Should I use c-structs and use c-function to work on them? Isn't there a better choice?
Thanks.
You can't do this. This isn't how Objective-C works (at least the Apple/GNU version*). It simply isn't designed for that sort of extreme low-level efficiency. Objects are allocated in dynamic memory and their lifetimes are controlled by methods you call on them, and that's just how it works. If you want more low-level efficiency, you can either use plain C structs or C++. But keep in mind that worrying about this is pointless in 99% of circumstances — the epitome of premature optimization. Objective-C programs are generally very competitive with C++ equivalents both in execution speed and memory use despite this minor inefficiency. I wouldn't go for a more difficult solution until profiling had proved it to be necessary.
Also, when you're new to Objective-C, it's easy to psych yourself out over memory management. In a normal Cocoa (Touch) program, you shouldn't need to bother about it too much. Return autoreleased objects from methods, use setters to assign objects you want to keep around.
*Note: There was an old implementation of Objective-C called the Portable Object Compiler that did have this ability, but it's unrelated to and incompatible with the Objective-C used on Macs and iOS devices. Also, the Apple Objective-C runtime includes special support for Blocks to be allocated on the stack, which is why you must copy them (copy reproduces the block in dynamic memory like a normal object) if you want to store them.
What if I need an object to use static memory by default and to be copied instead of referenced?
You don't.
Seriously. You never need an object to use static memory or be allocated on the stack. C++ allows you to do it, but no other object oriented language I know does.
For example, I have an object Color with 3 int components r, g and b. I dont want these objects to be in dynamic memory and referenced when passing to functions, I want them immutable and to be copied like an int or a float.
Why do you not want the objects to be in static memory? What advantage do you think that gives you?
On the other hand it's easy to make Objective-C objects immutable. Just make the instance variables private and don't provide any methods that can change them once the object is initialised. This is exactly how the built in immutable classes work e.g. NSArray, NSString.
One solution that people use sometimes is to use a singleton object (assuming you only need one of the objects for your entire app's lifetime). In that case, you define a class method on the class and have it return an object that it creates once when it is first requested. So you can do something like:
#implementation MyObject
+ (MyObject *)sharedObjectInstance
{
static MyObject *theObject=nil;
if (theObject==nil)
{
theObject = [[MyObject alloc] init];
}
return theObject;
}
#end
Of course the object itself isn't what's being statically allocated, it's the pointer to the object that's statically allocated, but in any case the object will stick around until the application terminates.
There are times when you want to do this because you really only want one globally shared instance of a particular object. However, if that's not your objective, I'm not sure why you'd want to do what you're describing. You can always use the -copy method to create a copy of an object (assuming the object conforms to the NSCopying protocol) to manipulate without touching the original.
EDIT: Based on your comments above it seems you just want to have immutable objects that you can copy and modify the copies. So using -copy is probably the way to go.