On Wed, Sep 9, 2009 at 10:21 PM, John Engelhart
<email@hidden> wrote:
> (moved back to objc-language)
>
> On Wed, Sep 9, 2009 at 12:54 PM, Jens Alfke <email@hidden> wrote:
>>
>> On Sep 7, 2009, at 2:32 AM, John Engelhart wrote:
>>
>> To my recollection, I have never discussed this problem on the list. I
>> have
>> discussed the following:
>>
>> The list of things you've discussed already sounds effectively identical
>> to the point you brought up.
>
> They are not. The last issue was the compilers conformance with section
> 6.2.4 of the standard
> ( http://lists.apple.com/archives/objc-language/2009/Mar/msg00037.html ).
> That issue has nothing what-so-ever to do with interior pointers.
>
>>
>> Your question "Does the Mac OS X garbage collector support interior
>> pointers?" seems completely rhetorical, as you already know the answer (no)
>> and, as you say, have discussed the issue here before. So I don't see what
>> the point of your post was, other than to pick a fight.
>
> In all honesty, I did not know the collector did not support interior
> pointers. If you think that the message I reference above has anything to
> do with interior pointers, you should re-read it carefully. They are two
> very different, very distinct points / problems that are completely
> unrelated.
> The only way they become related is if you know the following private NSData
> implementation detail (that is not mentioned in the official documentation):
> -(const void *)bytes
> {
> return((const void *)(((char *)self) + sizeof(NSData))); // Pseudo..
> substitute sizeof for correct API call/info
> }
> Then, AND ONLY THEN, does the example provided in the documentation about
> interior pointers make any sense.
> I did not know this tiny, but critically important detail until bbum
> mentioned it in passing. Only then did the pieces fit together.
> So no, I did not know the collector supported interior pointers as you
> suggest.
>
>>
>> A) The compiler is generating code that violates the C standard.
>> B) Because of this, it significantly complicates writing code that uses
>> garbage collection.
>>
>> I understand your reasoning with point A, but I don't think it's valid.
>
> Ohhh.. but it most certainly is! Consider the following:
> example_A {
> NSData *myData = [someObject getMyData];
> const uint8_t *bytes = [myData bytes];
> // .... lots of stuff, myData never referenced again
> }
> example_B {
> const uint8_t *bytes = [[someObject getMyData] bytes];
> // .... lots of stuff
> }
> To the inexperienced C programmer, these two examples "are the same".
> However, these two these have very, VERY different semantics. The compiler
> is extremely sensitive to these seemingly pedantic differences.
As far as a conforming program is concerned, the two are identical.
Yes, in A, the storage for myData must exist until the end of the
scope. However, no conforming C program could ever tell the difference
(i.e. the only way to see if myData still exists is to use it at some
later point. There is no possible way for a conforming X program to
tell the difference between "end of scope" and "immediately after last
use". Period.
Please explain how you can tell wether the storage for i is gone at
point "A" or point "B" in a conforming C program (hint, you cannot.)
{
int i = 42;
printf("%d\n", i);
//A
puts("I printed a 42");
//B
}
Because a conforming program cannot tell the difference, the compiler
is absolutely allowed to re-use i's storage for something else at
point "A" (or any point thereafter). Yes, this can have unfortunate
side-effects for the Obj-C GC in MacOS X; No, this is not an issue of
GCC/clang not conforming to 6.2.4.
--
Clark S. Cox III
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Objc-language mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
