[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PATCH: Merge objc-improvements-branch to mainline

From: Ziemowit Laski
Subject: Re: PATCH: Merge objc-improvements-branch to mainline
Date: Wed, 24 Sep 2003 12:09:34 -0700

On Wednesday, Sep 24, 2003, at 10:48 US/Pacific, Alexander Malmberg wrote:
The documentation for these does not seem to be correct, or at least not
consistent with the implementation. It seems that -fzero-link does what
-freplace-objc-classes is documented to do, and -freplace-objc-classes
emits a marker that tells the runtime that the implementations in the
file should override any earlier implementations.

Quite possibly, I've switched those around. :-) I'll double-check; thanks
for noticing this.


... this is not. This is just a bunch of syntactic sugar; making
language extensions and new keywords out of functionality that is
currently implemented in libraries.

Well, aside from the valid reasons Stan presented for adding exception and
synchronization syntax, I'd like to add 2 more:
 - Not all of it is syntactic sugar -- witness @finally (and hence
   @synchronized, which relies on finalization), which is extremely
   difficult do get right "by hand";
- The new exception syntax brings us closer to what C++ and Javaoffers in this regard. Although presently ObjC exceptions rely on _setjmp/_longjmp for binary compatibility with Foundation, in the future we may flip the switch and make it interoperable with C++ EH/RTTI machinery -- or with Java
   -- and just ask developers to recompile their code.

(Additionally, the documentation for @synchronize is very vague.)

I'm certainly open to suggestions as to how to improve this.

The only "known defect" of the patch is that not all of the
-fobjc-exceptions stuff
is as platform-independent as it could/should be.

Indeed. It seems that it's even hard-coding the size of libc structures
(jmp_buf), which is a bug problem for portability. (Are we even
guaranteed that the size is constant for a system and doesn't vary with
different libc:s?)

Yes, we should definitely rework this in the future, as I mentioned in my patch.

As for the sizeof(jmpbuf) issue, I don't think we're in any more trouble than
any vanilla C program utilizing setjmp/longjmp. :-)

Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477

reply via email to

[Prev in Thread] Current Thread [Next in Thread]