Ambiguity in definition of setjmp/longjmp makes them much less useful

[Tim McDaniel]

I don't know how Rodney Radford (sasrer at unx.sas.com) managed to get
almost everything exactly backwards.  Someone must have really
misinformed him.

He writes:

> ANSI chose not to make any of the functions special case so that an
> application may redefine the functions (although this is frowned
> upon in some cases).

>From section 4.1.2.1, "Reserved Identifiers", of the ANSI C standard
(page 98):

   All identifiers with external linkage in any of the following
   sections (including the future library directions) are always
   reserved for use as identifiers with external linkage.

So it's not "frowned upon" to redefine ANSI C functions as functions;
it's undefined, and it often won't work in practice.


> The reason for the ambiguity is because ANSI chose not to make
> setjmp/longjmp functions known by the C compiler so that it just
> treats them just like any other functions (ie: does not force local
> automatics values from registers to storage).

Section 4.6, page 119:

   It is unspecified whether setjmp is a macro or an identifier
   declared with external linkage.  If a macro definition is
   suppressed in order to access an actual function, or a program
   defines an external identifier with the name setjmp, the behavior
   is undefined. . . .
   
   An invokation of the setjmp macro shall appear only in one of the
   following contexts:
   
   - the entire controlling expression of a selection or iteration
     statement;
   
   - one operand of a relational or equality operator with the other
     operand an integral constand expression, with the resulting
     expression being the entire controlling expression of a selection
     or iteration statement;
   
   - the operand of a unary ! operator with the resulting expression
     being the entire controlling expression of a selection or
     iteration statement; or
   
   - the entire expression of an expression statement (possibly cast
     to void).

So setjmp may indeed be special.  Note that "&setjmp" is not
permitted, nor is "*fp" where fp points to the underlying setjmp
function (if any).  Thus, setjmp can always be "known by the C
compiler", if the compiler chooses to look.  Thus, a compiler can
always determine which functions call setjmp.


> The setjmp/longjmp functions themselves do not have the required
> information to force the values from the registers, so we are stuck
> with this oddity.

Section 4.6.2.1, page 120:

   the values of objects of automatic storage duration that are local
   to the function containing the invokation of the corresponding
   setjmp macro that do not have volatile-qualified type and have been
   changed between the setjmp invocation and longjmp call are
   indeterminate.

The functions themselves (if they exist) do not.  By the previous
section, however, the *compiler itself* has enough information, and it
can choose to 'do the right thing'.


> I believe (just guessing really) that the original C used 'builtins'
> for the setjmp/longjmp functions, ie: they special cased them.

To the best of my knowledge, the original several generations of C
compilers did not special-case them.  I'd be surprised if any
"standard" compilers (SUN OS, SYS V for VAXen, et cetera) have ever
done special-cased any functions.
--
Tim McDaniel                 Applied Dynamics Int'l.; Ann Arbor, Michigan, USA
Work phone: +1 313 973 1300                        Home phone: +1 313 677 4386
Internet: mcdaniel at adi.com                UUCP: {uunet,sharkey}!amara!mcdaniel