This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [basic-improvements] try/finally support for c/c++ - more tests
Zack Weinberg <zack@codesourcery.com> writes:
| On Thu, Nov 07, 2002 at 03:14:25AM +0100, Gabriel Dos Reis wrote:
| > Zack Weinberg <zack@codesourcery.com> writes:
| >
| > | p.s. It would be nifty if setjmp/longjmp could be defined in terms of
| > | exception handling. Anyone put thought into that?
| >
| > EH in C++ sense essentially makes control flow flows one direction
| > whereas setjmp/longjmp transfers control virtually anywhere.
|
| Imagine a setup like this:
|
| class jmp_buf {
| int setjmp_return_value;
| } __attribute__ ((always_passed_by_reference));
|
| void calls_longjmp(jmp_buf env)
| {
| env.setjmp_return_value = 1;
| throw env;
| }
|
| void calls_setjmp(void)
| {
| try {
| jmp_buf env;
| env.setjmp_return_value = 0;
|
| control_transfers_here_twice:
| if (env.setjmp_return_value == 0) {
| puts("first call to setjmp()");
| calls_longjmp(env);
| } else {
| puts("second call to setjmp()");
| }
|
| } catch (jmp_buf E) {
| if (&E != &env)
| throw;
| goto control_transfers_here_twice;
| }
| }
|
| The "always_passed_by_reference" bit ensures that when control
| transfers to the catch clause, &E == &env if and only if it was
| 'env' that got longjmped to.
I'm not sure that extra linguistic facility is really in accordance
with C++ rules (I'm not sure 12.8/15 applies here). Furthermore after
call to calls_longjmp(), the object env ceases existing -- it isn't
even visible in the catch block so I assume you wanted
jmp_buf env;
try {
env.setjmp_return_value = 0;
// ...
[...]
| I claim that any use of setjmp/longjmp that won't work with this
| implementation is already invoking undefined behavior.
Well, let's first address the case of situations that "work" with the
above scheme before addressing the validity of the claim. What is
supposed to happen for the rethrow case?
-- Gaby