Re: NSString* kMyKey = @"aKey" vs #define MYKEY @"aKey"
Re: NSString* kMyKey = @"aKey" vs #define MYKEY @"aKey"
- Subject: Re: NSString* kMyKey = @"aKey" vs #define MYKEY @"aKey"
- From: Dave Keck <email@hidden>
- Date: Fri, 3 Apr 2009 16:32:52 -1000
> As for read-only address space, does the const declaration not take care of
> that? (Serious question.)
I just tested whether it's possible to write at the address of an
NSString declared with either:
NSString *const HelloString = @"ABC123";
#define GoodbyeString @"XYZ345"
(If you're interested, you can download my test project here:
http://www.docdave.com/halla.zip)
In both cases, I was able to write to the address of the string
without crashing. I found this surprising, because I assumed at least
HelloString would be stored in the read-only _TEXT segment...
According to otool (otool -l), the _cstring section of the _TEXT
segment for my test app starts at the decimal offset 3740 in the
binary. With my handy HexEdit, I went to this offset, and sure enough,
there's my 'ABC123' and 'XYZ345'. (Perhaps I should also note that the
_cstring section is the only place where these two strings appear in
the binary.)
So it seems that the strings are stored as C strings in the binary
(not surprising, I guess) but are automagically converted to NSStrings
at runtime. These runtime-generated NSStrings are stored in a
read-write portion of the processes' address space, which is why I was
able to write directly to their addresses.
So I guess this is getting OT, but if someone (perhaps, The Runtime
Wrangler :)) knows how this works, I'd love to know.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden