[cfe-dev] Fix for PR4701

[Jean-Daniel Dupas]

Le 15 août 2009 à 21:50, Ken Ferry a écrit :

> On Sat, Aug 15, 2009 at 4:31 AM, David Chisnall  
> <csdavec at swansea.ac.uk> wrote:
> On 15 Aug 2009, at 02:37, Daniel Dunbar wrote:
>
> > On Fri, Aug 14, 2009 at 6:30 PM, David
> > Chisnall<csdavec at swansea.ac.uk> wrote:
> >> I'd like to keep it.  Long-term, I agree with Steve - having  
> explicit
> >> typedefs for what should be builtin types is an ugly hack.  If we
> >> leave it
> >> in then users can slowly drop the includes of the headers that
> >> define these
> >> types and fall back to using the compiler-supplied definitions.  In
> >> a little
> >> while we can add a warning for files that define these types.
> >
> > To clarify, so your position is that long term clients should drop
> > uses of the other fields, but direct assignment / reading of isa is
> > ok?
>
> Yes.  The Apple runtime.h already marks the fields other than isa as
> deprecated with the legacy runtime and unavailable on the modern
> runtime.
>
> > One downside of that approach (aside from being speculative) is that
> > it encourages users to write non-portable (to gcc) code. Since it is
> > also speculative it seems to me to unnecessarily complicate clients,
> > but I'm happy to defer to others opinions on this.
>
> Not really a problem for the GNU runtime - any code that uses
> properties or fast enumeration will compile with clang but not GCC
> already because no one seems to be working on Objective-C in the FSF's
> tree and the Apple tree doesn't support the GNU runtime.  People using
> the Apple runtime almost always get these definitions via Foundation.h
> (often indirectly via Cocoa.h), so there's little chance of them
> accidentally writing code that doesn't include them (although a future
> version of the Apple headers may choose to wrap their definitions in
> #ifndef __clang__).
>
> Why the exemption for isa?
>
> Isa is certainly more popular to access than other fields, but  
> there's no reason not to go through runtime functions.
>

Actually, isa is a protected ivar of NSObject. Excepted if this field  
visibility is changed to private, I don't think you can change the isa  
type without breaking compatibility.