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