Re: Accessing buffers in NSData/NSMutableData under garbage collection

FROM : Quincey Morris
DATE : Tue Feb 19 19:36:37 2008

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?