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

[Ziemowit Laski]

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.

> > -fobjc-exceptions
>
> ... 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. :-)

--Zem
--------------------------------------------------------------
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