On Aug 15, 2012, at 4:46 PM, John McCall <rjmcc...@apple.com> 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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
