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