On Aug 7, 2012, at 9:43 AM, jahanian <[email protected]> wrote:
>
> On Aug 6, 2012, at 5:42 PM, Jordan Rose wrote:
>
>>
>> On Aug 6, 2012, at 17:37 , Fariborz Jahanian <[email protected]> wrote:
>>
>>>
>>> On Aug 6, 2012, at 5:09 PM, Jordan Rose wrote:
>>>
>>>> Why does this only warn under non-GC?
>>>
>>> I don't know. This is an old GCC option and brought it over as-is to clang.
>>> I don't have the original gcc radar
>>> to look for the rational. Could be that under GC it is safe to do direct
>>> assignment while with the advent of
>>> properties, users warn to catch such accesses and use the property syntax
>>> which controls the ivar
>>> access with its own APIs (think atomic vs non-atomic).
>>
>> The same is true under ARC, though. If this is a safety warning, it only
>> really needs to be on for MRC and __unsafe_unretained ivars. I think it's
>> more often a consistency thing, though: if you want Key-Value Observing to
>> work right you have to use the properties.
>>
>> As a heuristic, people often access ivars directly in -init methods and in
>> -dealloc, since properties may be overridden by subclasses. If we were going
>> to split the difference on the warnings, it could be on by default
>> everywhere except -init and -dealloc methods.
>
> My intention was to closely follow gcc's behavior wrt -Wdirect-ivar-access.
There's no point in modeling GCC 4.2's behavior, because it isn't relevant for
Objective-C. Wdirect-ivar-access is intended to warn about direct access to
ivars in places where one should probably have accessed a property instead.
That has nothing to do with GC or ARC, so the warning should not dependent on
the (absence of) those features.
- Doug
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
