This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]