Converting FORTRAN to C
Brandon Allbery the tame hacker on the North Coast
bsa at ncoast.UUCP
Sat Jan 5 00:59:45 AEST 1985
Having just yesterday sent a response to a message denying that Cuses
contiguous storage, I find myself with egg on my face, having been bitten
by that feature of C that I love to hate: the fact that the apparent
and real semantics of array declarations are wildly at variance with
each other. The C compiler goes to great lengths to make
int a[5][2];
look like
a ----> (a1) (a2) (a3) (a4) (a5)
| | | | |
V V V V V
(a1.1) (a2.1) (a3.1) (a4.1) (a5.1)
(a1.2) (a2.2) (a3.2) (a4.2) (a5.2)
...but `a' is really a constant and a1, a2, a3, a4, a5 have no objective
existance at all. This really galls me; why make it look like something
it cannot be? The pointer model takes up more memory, but has quite
a few advantages over the block data (forgive me, ForTran-ers! :-) model.
I would prefer that, consistent with the rest of the pointer/array equi-
valency, array[][] were REALLY equivalent to **array. The latter is
used more often (strings) anyway.
It's too late to save C. I'm still working on a C-like language which
uses my idea of pointers/arrays. (Unfortuantely, our lex has shown a
regrettable tendency to core-dump for no reason at all, and generated
programs (if it doesn't coredump) also usually dump core.)
--bsa
--
Brandon Allbery @ decvax!cwruecmp!ncoast!bsa (..ncoast!tdi1!bsa business)
6504 Chestnut Road, Independence, Ohio 44131 (216) 524-1416
Who said you had to be (a) a poor programmer or (b) a security hazard
to be a hacker?
More information about the Comp.lang.c
mailing list