Re: __weak pointer collection firing prematurely???
Re: __weak pointer collection firing prematurely???
- Subject: Re: __weak pointer collection firing prematurely???
- From: Britt Durbrow <email@hidden>
- Date: Wed, 15 Aug 2012 18:00:31 -0700
On Aug 15, 2012, at 4:46 PM, John McCall <email@hidden> wrote:
> On Aug 13, 2012, at 11:38 PM, Britt Durbrow wrote:
>> OK, I think I've isolated the issue... basically, __weak, @public, and -fno-objc-arc don't like to play nice together. If you set a @public __weak instance variable (may also apply to stack variables, I haven't tested that yet) in a file compiled with -fno-objc-arc, and then access it in a file compiled with ARC turned on, the variable gets zeroed out.
>>
>> I have reduced it to a simple test project, and I'm going to file a RADAR.
>
> Please do; maybe we can find a way to warn about the assignment to a __weak object in non-ARC. That said, your code is buggy; we do *not* guarantee anything about the representation of a weak object, and it is not legal to access one in non-ARC code except by explicitly calling one of the specified runtime functions (and we don't encourage you to do that).
>
> John.
Done. rdar://12101247
The ARC documentation does not seem to indicate that the appropriate runtime function is not emitted by the compiler when -fno-objc-arc is in effect... and given that it's automatic *retain counting* that I thought I was turning off; and not other parts of the runtime system, it's kinda counterintuitive (well, it is to me at least :-) to have the compiler silently generate erroneous code - especially when the result is a value changing on a *read* operation!
I would expect either: a) the compiler would always emit the correct runtime call for a __weak assignment no matter if ARC is on or off; or b) the compiler would throw an error when an attempt to access a __weak variable is made without ARC turned on (I don't think a warning is sufficient; given that it really does mess things up). If the runtime functions that implement the __weak access system are written in C and need to be able to emit a low-level primitive pointer access to avoid recursion, perhaps adding a compiler flag to disable the error (and cause the existing direct access to be emitted) or having it emit a direct access when the variable is explicitly cast to a non __weak type would handle that issue - in other words
__weak id someVar;
((void *)someVar)=aNewValue;
could be setup to only generate mov opcodes; and not a call into the runtime. (Obviously, if it's in fact written in assembler, then recursive call emission won't be an issue :-)
_______________________________________________
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