• 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: Accessing buffers in NSData/NSMutableData under garbage collection
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Accessing buffers in NSData/NSMutableData under garbage collection


  • Subject: Re: Accessing buffers in NSData/NSMutableData under garbage collection
  • From: Quincey Morris <email@hidden>
  • Date: Tue, 19 Feb 2008 10:36:37 -0800


On Feb 19, 2008, at 03:48, Alastair Houghton wrote:

Indeed, the following code is broken, but only when compiled using optimization:

/* ---- tst.m ----------------------------------------------------- */

 #import <Foundation/Foundation.h>

 int
 main (int argc, char **argv)
 {
   float *myArray = NSAllocateCollectable(1000 * sizeof(float), 0);
   unsigned n;
   float *ptr;

   for (n = 0, ptr = myArray; n < 100; ++n, ++ptr) {
     *ptr = 1.0;
   }

   [[NSGarbageCollector defaultCollector] collectExhaustively];

   for (n = 0; n < 100; ++n, --ptr) {
     printf ("%f\n", *ptr);
   }

   return 0;
 }

Another way of looking at this is that the following is implicit in the above:


__strong float *myArray = NSAllocateCollectable(1000 * sizeof(float), 0);
unsigned n;
__strong float *ptr;


   for (n = 0, ptr = myArray; n < 100; ++n) {
     *ptr = 1.0;
     ptr = ptr + 1;
   }

and that 'ptr + 1' isn't really compatible with the __strong variable it's being assigned to. (If the runtime supported interior pointers, it would be compatible.) That incompatibility is a can of worms, if you imagine the effects of having the compiler flag it as an error, but at least it's a purely syntactic can of worms.

Furthermore, your example made me wonder if there's another optimization hole, that has nothing to do with interior pointers, but which also reflects a variable lifetime indeterminacy:

  __weak NSString* string1 = [@"string1" copy];
  NSString* string2 = @"string2";
  [[NSGarbageCollector defaultCollector] collectExhaustively];

Couldn't this result in the garbage collector zeroing 'string2' under unlucky (but common) optimization conditions?

_______________________________________________

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


  • Follow-Ups:
    • Re: Accessing buffers in NSData/NSMutableData under garbage collection
      • From: "Michael Ash" <email@hidden>
References: 
 >Accessing buffers in NSData/NSMutableData under garbage collection (From: Rick Hoge <email@hidden>)
 >Re: Accessing buffers in NSData/NSMutableData under garbage collection (From: Adam P Jenkins <email@hidden>)
 >Re: Accessing buffers in NSData/NSMutableData under garbage collection (From: mmalc crawford <email@hidden>)
 >Re: Accessing buffers in NSData/NSMutableData under garbage collection (From: Adam P Jenkins <email@hidden>)
 >Re: Accessing buffers in NSData/NSMutableData under garbage collection (From: Adam P Jenkins <email@hidden>)
 >Re: Accessing buffers in NSData/NSMutableData under garbage collection (From: Chris Suter <email@hidden>)
 >Re: Accessing buffers in NSData/NSMutableData under garbage collection (From: Alastair Houghton <email@hidden>)

  • Prev by Date: *** -[NSCFDictionary setObject:forKey:]: mutating method sent to immutable object
  • Next by Date: Re: Accessing buffers in NSData/NSMutableData under garbage collection
  • Previous by thread: Re: Accessing buffers in NSData/NSMutableData under garbage collection
  • Next by thread: Re: Accessing buffers in NSData/NSMutableData under garbage collection
  • Index(es):
    • Date
    • Thread