Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!caen!umich!sharkey!amara!mcdaniel From: mcdaniel@adi.com (Tim McDaniel) Newsgroups: comp.lang.c Subject: Re: Ambiguity in definition of setjmp/longjmp makes them much less useful Message-ID: Date: 9 Oct 90 21:40:53 GMT References: <1597@redsox.bsw.com> <1990Oct09.143521.24019@unx.sas.com> Sender: news@adi.COM Organization: Applied Dynamics International, Inc.; Ann Arbor, Michigan, USA Lines: 88 In-reply-to: sasrer@unx.sas.com's message of 9 Oct 90 14:35:21 GMT I don't know how Rodney Radford (sasrer@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@adi.com UUCP: {uunet,sharkey}!amara!mcdaniel