This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Merging Apple's Objective-C 2.0 compiler changes

On Fri, Sep 10, 2010 at 11:13 AM, Richard Guenther
<> wrote:
> Btw, we do seem to have code in GCC that is not copyrighted by the FSF.
> For example I don't think the FSF owns copyright on the ACATS
> testsuite, and libffi mentions (c) by RedHat.

That code is not part of the compiler proper. The policy has always
been different for the test suites and for runtime libraries.

> Thus, if getting the copyright assigned to the FSF for the ObjC changes
> proves to be impossible I'd suggest to ask the SC for a policy
> exception.

IMHO the risk of "leakage" of such code to places outside the ObjC
front end would be too big.

To be completely honest: I think Nicola's efforts are laudable but I
wonder whether it helps GCC-the-project more than it hurts. GNU ObjC
has so few users that it seems hardly worth the effort to upgrade the
GNU ObjC front end to ObjC 2.0. And there are other issues:

* What standard is going to be implemented? ObjC 2.0 is not even a
documented language standard, so you probably end up with something
that is incompatible with Apple ObjC anyway. Without a documented
standard, the only "standard" is the Apple compiler, which you cannot
look at without risking copyright problems. The latest state of ObjC
2.0 on apple branches on may not be the "current" ObjC

* How do ObjC 2.0 and ObjC++ interact? Even now, there is already the
problem of the two exception handling models, and AFAIU that will only
get more complicated with ObjC 2.0.

* What does it mean for existing GNU ObjC users to make the headers
and runtime compatible with NEXTnow? These changes break source
compatibility, I guess, and if that is indeed the case then the
question is whether that is acceptable or not.

Not that I want to discourage anyone. Just practical considerations...
;-)  I can't believe I'm saing this but: It may be better to spend
some effort on making clang work as a GCC front end.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]