[vox-tech] For "C" gurus

Harold Lee harold at hotelling.net
Thu Dec 7 12:45:58 PST 2006


Jeff Newmiller wrote:
> Richard Harke wrote:
>> But suppose this is changed to the following:
>>
>> int
>> asub(jmp_buf env)
>> {
>> .....do something
>>     longjmp(env, 1);
>> }
>>
>> int
>> my_wrapper(jmp_buf env)
>> {
>>     int x;
>>
>>     if (x = setjmp(env)) {
>>          return x;
>>      } else {
>>             return 0;
>>      }
>> int
>> main()
>> {
>>     jmp_buf env;
>> /*init*/
>> some code
>>      if (my_wrapper(env);) {
>> /* returned from longjmp */
>>         clean up
>>         exit(0);
>>     } else {
>> /*just returned from setjmp */
>>     asub(env);
>>         may not return
>>     }
>> }
>>
>> Notice that because we returned from my_wrapper before
>> calling asub, the local variables for asub have been
>> removed from the stack. Thus they cannot be restored
>> by the longjmp. It seems to me this usage should
>> be explicitly rejected. Can any one point me to an
>> authoratative reference that says this?
>
> I don't have the latest standard, but this is covered in ANSI X3.159-1989
> Section 4.6.2.1 lines 7-10:
>
>   The longjmp function restores the environment saved by the most recent
>   invocation of the setjmp macro in the same invocation of the 
> program, with
>   the corresponding jmp_buf argument.  If there has been no such 
> invocation,
>   or if the function containing the invocation of the setjmp macro has
>   terminated execution in the interim, the behavior is undefined.
>

Wikipedia has a good article on the subject that should scare you away 
from using my_wrapper:
http://en.wikipedia.org/wiki/Longjmp



More information about the vox-tech mailing list