setjmp and typedef'd arrays; thoughts on &array

Brandon Allbery bsa at ncoast.UUCP
Mon Oct 8 06:47:11 AEST 1984


I think I have to clarify what I said in my last posting on this -- I
didn't explain why the &array was a no-no.  Forgive me if this is common
knowledge.

C purportedly handles arrays as if they were blocks of data and pointers.
However, it doesn't, quite.  The declaration

	char **foo, bar[10];

should allow me to say

	foo = &bar;

later on.h, since bar should be a pointer to char.  Unfortunately, bar
is what I call a VIRTUAL pointer -- it assembles as a literal (look at
your compiler's output).  To work correctly, it would have to assemble
to a constant pointer which always points to a particular block of memory,
in which case the above would work.  (Notice that the above is essentially
the jmp_buf, expanded.)  Instead, there is no such thing as &bar because
bar is not a variable, it is a literal.

One solution to this is to implement arrays as I showed above (in fact,
I considered writing a C-like language which used something like

	char ch*5; /* a (char *) whose value is the address of a block
		      of 5 characters */

but I don't think I can resolve possible conflicting uses of *); another
is to treat the jmp_buf typedef as having an implicit struct definition,
in which case the syntax

	jmp_buf *foo, bar;
	bar = &foo;

would expand to

	struct __jmp_buf {char jmp_buf[10];} *foo, bar;
	bar = &foo;

and since &struct is legal, it would work.  I think typedef should do
something like this, with `invisible' structs.  Anyone see problems with
it? (Probably; I've only been at this for a year. :-)

--bsa



More information about the Comp.lang.c mailing list