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: Alexander Malmberg <alexander at malmberg dot org>
- To: Ziemowit Laski <zlaski at apple dot com>
- Cc: gcc-patches at gcc dot gnu dot org, discuss-gnustep at gnu dot org
- Date: Thu, 25 Sep 2003 18:50:54 +0200
- Subject: Re: PATCH: Merge objc-improvements-branch to mainline
- References: <A25CE27A-EEC2-11D7-9E98-00039390FFE2@apple.com>
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?
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.
[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.)
- Alexander Malmberg