setjmp and typedef'd arrays; thoughts on &array

[Sam Kendall]

>     "setjmp foo, *tmp; tmp = &foo;" is accepted with no complaints by my C
> compiler (based on the Dennis Ritchie V7 PDP11 "cc"), as it should be, because
> "tmp" and "&foo" have exactly the same (defined) type.
> -- 
> 			    Morris M. Keesan

   (I think you mean "jmp_buf foo, *tmp;".) The manual page implies that
jmp_buf is typedef'd to an array type, since the calls wouldn't work if
it weren't--you'd have to say "setjmp(&foo)" instead of "setjmp(foo)".
Sure enough, all UNIX implementations make jmp_buf an array type.  Now,
the type of "tmp", pointer to array, is fine, but the expression "&foo"
in "tmp = &foo" is not, because it is not legal to take the address of
an array with the address-of operator (somewhere in the Ref Man it says
an array is never an lvalue).  "&array" works on Ritchie cc's anyway,
as you note; but, quite properly, it won't work on others --in most
PCC's, the "&" is ignored.  "tmp = (jmp_buf *) foo" will work.

   Someone suggested that ATT allows assignment of jmp_buf's, etc.; this
is totally wrong (unless he is using a bizarre internal dialect).

> From: nazgul at apollo.uucp (Kee Hinckley)
> The whole point of a typedef (in my mind at least) is to create a
> level of abstraction that alleviates the need to learn what the machine/
> compiler architecture actually looks like.  To a certain degree typedef
> seems to succeed at this, but then it all falls apart.  Any thoughts?

   I agree, although the point is also to abstract away from what the
typedef'd type actually is, not just from the machine; the problem here
is that arrays behave differently from other types in C, and you can get
bitten with typedef'd arrays such as jmp_buf.  I feel strongly that one
should be able to take the address of an array with the address-of
operator, for reasons of orthogonality--in other words, so that the bite
would be a little less harsh.  The issue came before the ANSI C
committee this last meeting, and was voted down, so "&array" still
doesn't work.  The members seemed to feel that it was an extension,
rather than the removal of an anomalous restriction.  I have a pretty
good justification for feeling otherwise, which I'll post at some
point.

	Sam Kendall	  {allegra,ihnp4,ima,amd}!wjh12!kendall
	Delft Consulting Corp.	    decvax!genrad!wjh12!kendall