PATCH: Merge objc-improvements-branch to mainline

Ziemowit Laski
Thu Sep 25 21:10:00 GMT 2003

On Thursday, Sep 25, 2003, at 09:50 US/Pacific, Alexander Malmberg 

> Ziemowit Laski wrote:
>> On Wednesday, Sep 24, 2003, at 10:48 US/Pacific, Alexander Malmberg
>> wrote:
> [snip]
>>   - 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.
> This sounds worrying. Currently, your extensions are explicitly
> documented as not interacting with c++'s exceptions. Do you intend to
> change this?

At some unspecified point in the future, when it becomes possible to
break binary compatibility, we hope to be able to move to the C++ EH

> Introducing a bunch of extensions only to change their semantics later
> does not seem like a particularly good idea. If it is so, I would
> suggest that you at least add a warning in the documentation that this
> part of the semantics should not be relied on since it might change.

The semantics will not change; the only thing that _may_ change
is the implementation thereof.

> [snip]
>> As for the sizeof(jmpbuf) issue, I don't think we're in any more
>> trouble than
>> any vanilla C program utilizing setjmp/longjmp. :-)
> A vanilla c program can simply include setjmp.h and get the right
> definition of the struct. How do you propose that the compiler figure
> out the size with no more trouble than that (and, as the comment says,
> without forcing setjmp.h to be included)? (I can think of several
> solutions, but none that wouldn't involve a lot trouble.)

Yes, I agree that having the user #include <setjmp.h> would be a far
cleaner way; this was shot down at Apple internally. :-(  Of course,
when you guys do the GNU runtime port, you can either (1) require
<setjmp.h> to be included, or (2) use C++ EH.  Failing that, a
'jmpbuf_size' target hook could be put in whereby different platforms
could inform us of their requirements.

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

More information about the Gcc-patches mailing list