This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: Merge objc-improvements-branch to mainline
- From: Ziemowit Laski <zlaski at apple dot com>
- To: Alexander Malmberg <alexander at malmberg dot org>
- Cc: gcc-patches at gcc dot gnu dot org, discuss-gnustep at gnu dot org
- Date: Thu, 25 Sep 2003 14:06:29 -0700
- Subject: Re: PATCH: Merge objc-improvements-branch to mainline
On Thursday, Sep 25, 2003, at 09:50 US/Pacific, Alexander Malmberg
wrote:
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
model.
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.
--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