Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP Path: utzoo!linus!decvax!genrad!mit-eddie!godot!harvard!seismo!rlgvax!guy From: guy@rlgvax.UUCP (Guy Harris) Newsgroups: net.lang.c Subject: Re: typedef gripe Message-ID: <170@rlgvax.UUCP> Date: Sat, 6-Oct-84 03:02:53 EDT Article-I.D.: rlgvax.170 Posted: Sat Oct 6 03:02:53 1984 Date-Received: Sun, 7-Oct-84 21:49:46 EDT References: <22286ae4.8e4@apollo.uucp> <18@mit-athena.ARPA> Organization: CCI Office Systems Group, Reston, VA Lines: 20 >...> Discussion of "jmp_buf" typedefed as an array causing various >...> compilation errors. > > Apollo is correct and Berkeley is wrong at least as I understand how C > compilers work at ATT. A jmp_buf is not exactly an array. It is a > fixed length, array, i. e. a block of memory of known size a.k.a > structure. Not as of System V Release 2; it's still an array, not a structure, in the include file "setjmp.h". Thus, the example you give later of structure copying between "jmp_buf"s won't work either. Maybe some non-mainstream versions of UNIX have defined it as a structure (it probably should be so defined, 1) because it doesn't do any harm, 2) because structures, unlike arrays, can be dealt with in a semi-abstract fashion and won't cause problems when you stick an "&" in front of one's name, and 3) because that way you can put mnemonic names on the elements of the jmp_buf, so you can figure out "OK, it sticks the current frame pointer in the fifth word"). Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy