Public Comment Number PC-UK0287 ISO/IEC CD2 9899 (SC22N2794) Public Comment =========================================== Date: 1998-12-17 Author: C.D.W.Feather Author Affiliation: Self Postal Address: Demon Internet Ltd. 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Category: Clarification Committee Draft subsection: 7.13, 7.13.2.1 Title: Clarify what the setjmp "environment" is Detailed description: Much of the state of the abstract machine is not stored in "objects" within the meaning of the Standard. It needs to be clear that such state is not saved and restored by the setjmp/longjmp combination. Append to 7.13p2: The environment of a call to the setjmp macro consists of information sufficient for a call to the longjmp function to return execution to the correct block and invocation of that block (if it were called recusively). It does not include the state of the floating-point flags, of open files, or of any other component of the abstract machine. In 7.13.2.1p3, change: All accessible objects have values as of the time ... to All accessible objects have values, and all other components of the abstract machine [*] have the same state as of the time ... [*] This includes but is not limited to the floating-point flags and the state of open files. It also needs to be clear that optimisers need to take care. Consider the following code: jmp_buf env; int v [N * 2]; for (int i = 0; i < N; i++) { v [2*i] = 0; if (setjmp (env)) // ... v [2*i+1] = f (); // might call longjmp; note i hasn't changed } This might be optimised as if written as: jmp_buf env; int v [N * 2]; for (ii = 0; ii < 2 * N; ) { v [ii] = 0; if (setjmp (env)) // ... ii++; v [ii] = f (); // might call longjmp ii++; } Such code would be allowed to make ii indeterminate after a longjmp, but the original code would not. It should be made clear, perhaps through an example, that such an optimisation must allow for the possibility of a longjmp happening.