• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: __weak pointer collection firing prematurely???
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: __weak pointer collection firing prematurely???


  • Subject: Re: __weak pointer collection firing prematurely???
  • From: John McCall <email@hidden>
  • Date: Thu, 16 Aug 2012 15:10:57 -0700

On Aug 15, 2012, at 6:00 PM, Britt Durbrow wrote:
> 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!

Unless specifically indicated, everything in the ARC documentation is only enabled/valid under -fobjc-arc.  ARC's __weak semantics are new to ARC.  We did repurpose an existing "keyword" from GC, and it has roughly similar behavior, but that bites us here:  __weak was always ignored when GC was disabled, so changing that is source-breaking.

> 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).

We'll see whether we can emit a warning.  An error is unlikely.

John.


_______________________________________________

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

References: 
 >__weak pointer collection firing prematurely??? (From: Britt Durbrow <email@hidden>)
 >Re: __weak pointer collection firing prematurely??? (From: Britt Durbrow <email@hidden>)
 >Re: __weak pointer collection firing prematurely??? (From: John McCall <email@hidden>)
 >Re: __weak pointer collection firing prematurely??? (From: Britt Durbrow <email@hidden>)

  • Prev by Date: Re: launch application de-elevated
  • Next by Date: Re: launch application de-elevated
  • Previous by thread: Re: __weak pointer collection firing prematurely???
  • Next by thread: Re: __weak pointer collection firing prematurely???
  • Index(es):
    • Date
    • Thread