Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!henry From: henry@utzoo.UUCP (Henry Spencer) Newsgroups: net.lang.c Subject: Re: What is setjmp... Clarification and typedef gripe Message-ID: <4418@utzoo.UUCP> Date: Thu, 4-Oct-84 13:27:56 EDT Article-I.D.: utzoo.4418 Posted: Thu Oct 4 13:27:56 1984 Date-Received: Thu, 4-Oct-84 13:27:56 EDT References: <22197810.8e4@apollo.uucp>, <981@bbncca.ARPA> Organization: U of Toronto Zoology Lines: 33 >> jmp_buf foo, *tmp; >> ... >> tmp = &foo; >> $ cc foo >> >> (0008) tmp = &foo; >> ******** Line 8: Warning: Illegal pointer combination: incompatible types. > "setjmp foo, *tmp; tmp = &foo;" is accepted with no complaints by my C > compiler (based on the Ritchie V7 PDP11 "cc"), as it should be, because > "tmp" and "&foo" have exactly the same (defined) type... The problem, alas, goes deeper, and the Ritchie compiler is covering it up rather than solving it. The *real* problem is that many implementations typedef jmp_buf as an array, and &array is not a legal use of &. The old Ritchie compiler lets you get away with it, but more recent ones don't. I'm not sure just when &array was officially declared illegal; a quick glance at K&R doesn't find a statement to that effect, but there definitely is one in the recent ANSI draft. And pcc, even the old V7 one, does object. Note that casts don't really solve the problem; &array is *illegal*, and a strict compiler will reject it completely. This is a place where typedef isn't as opaque as it should be, alas. If jmp_buf is a struct, you must write "tmp = &foo;", whereas if it's an array you must write "tmp = foo;". Not good. Probably the best solution is to lean on your implementor to typedef jmp_buf as a struct instead of an array; that's probably a better way to do things all around. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry