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