Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site oliveb.UUCP
Path: utzoo!linus!decvax!decwrl!sun!qubix!ios!oliveb!jerry
From: jerry@oliveb.UUCP (Jerry Aguirre)
Newsgroups: net.lang.c
Subject: Re: C subscripts
Message-ID: <211@oliveb.UUCP>
Date: Thu, 1-Nov-84 22:13:33 EST
Article-I.D.: oliveb.211
Posted: Thu Nov  1 22:13:33 1984
Date-Received: Sat, 3-Nov-84 20:43:12 EST
References: <mouton.195> <202@oliveb.UUCP> <48@drivax.UUCP>
Organization: Olivetti ATC, Cupertino, Ca
Lines: 48

As I recall FORTRAN (gerr!) also varied the left most subscript
fastest.  That is, an array was stored in memory in the order:
		a[1,1], a[2,1], a[3,1], a[1,2], a[2,2] ...

Is anyone suggesting that we change the order of array storage?  Maybe
the notation a[1,2] would have the leftmost order and the notation
a[2][1] would have the rightmost?

And of course FORTRAN arrays always begin with a[1] instead of a[0].
I know a lot of people who get more confused by this than by the use of
a[0][0].  Pascal allows you to specify the starting value of the array.
Is anyone suggesting that we start arrays with other than 0?

Regarding enumerated types as array subscripts.  It would give a
cleaner appearance if the language allowed a typedef as a array size.
So that:
	typedef enum {red, blue, green} color;
	int value[color];

Would declare an array that could be subscripted with:
	value[red], value[blue], value[green]
    or:
	color x;
	value[x];

A warning or error message for an uncast subscript not of the correct
type would be ok.  But would this conflict with the proposed "enumerated
types as int" change?  Is the use of an typedef as an array size going
to confuse the syntax?

On PORTABILITY:  The comment that you should disallow a feature because
that feature can be used to write unportable code is unC like as well
as impractical.  I consider the ability to write unportable code in C
and advantage!  Remember there are several classes of code which are
implicitly not portable.  The bottom level of device drivers is an
obvious example.  No way is the code that twiddles the I/O bits going to
be portable because on any other machine the bits would be different.
Removing that unportable feature might make it impossible
to write device drivers in C.  That would put us back in the dark ages
where drivers are written in assembler or the systems group uses one
language and the applications another.  This is the main failing of
Pascal.  One can't write compilers, editors, linkers, or operating
systems with standard Pascal because it is so over protective.

Remember: languages don't write bad code, programmers do!

				Jerry Aguirre @ Olivetti ATC
{hplabs|fortune|idi|ihnp4|ios|tolerant|allegra|tymix}!oliveb!jerry