Re: What is the life of the c string returned by NSString's UTF8String method?
Re: What is the life of the c string returned by NSString's UTF8String method?
- Subject: Re: What is the life of the c string returned by NSString's UTF8String method?
- From: Jesper Storm Bache <email@hidden>
- Date: Fri, 18 Sep 2009 11:14:01 -0700
- Acceptlanguage: en-US
- Thread-topic: What is the life of the c string returned by NSString's UTF8String method?
On Sep 18, 2009, at 11:04 AM, Stuart Malin wrote:
> I am under the impression that the reference returned by NSString's
> UTF8String method is valid for the life of the NSString instance which
> provided the reference (and further, that the memory of the referenced
> C string is freed when the NSString is released). Is this correct?
If I read the documentation, I get a different impression:
===
The returned C string is automatically freed just as a returned object
would be released; you should copy the C string if it needs to store
it outside of the autorelease context in which the C string is created
===
To me that indicates that the returned string may be autoreleased
before the NSString is released.
Jesper
>
> I have a class with some (statically allocated) class variables. In
> the class's -initialize method, I create a retained NSString. I set
> one of the class variables to the value returned by -UTF8String (as
> sent to that retained NSString). I use this char* value in some C
> calls made from instance methods of the class.
>
> The first time an object of the class is instantiated, this works
> fine. But it seems that for subsequent instances, although the value
> of the char* pointer remains unchanged, the memory it is pointing to
> is changed (i.e., no longer a C string representation of the
> NSString). So, either the NSString has done something with the memory
> pointed to by the initialized reference (i.e., I can't hold onto the
> reference as I have been), or somehow the memory is getting corrupt in
> some other way. I will look into the latter but only if my assumption
> about the former is correct.
>
> TIA.
>
>
> _______________________________________________
>
> 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
_______________________________________________
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