[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