Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1a 7/7/83; site rlgvax.UUCP
Path: utzoo!linus!philabs!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.lang.c
Subject: Re: mixing pointers and arrays
Message-ID: <993@rlgvax.UUCP>
Date: Sat, 13-Aug-83 02:34:47 EDT
Article-I.D.: rlgvax.993
Posted: Sat Aug 13 02:34:47 1983
Date-Received: Sun, 14-Aug-83 00:18:04 EDT
References: <961@rlgvax.UUCP>, <673@watcgl.UUCP>,  <1737@allegra.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 27

P.S.  I also think that the equivalence between array names and
array addresses wasn't necessarily a good idea, given the problems it
seems to cause.  (Please, no "UNIX wasn't intended for novices" flames;
it's going to be used by novices whether you like it or not.)  I certainly
don't make use of it unless forced to do so by "lint"'s complaining about

	int foo[10];
	int *bar;

	bar = &foo;

I think that the current rules mix two concepts (pointers and arrays) in
a way that is often unclear and occasionally dangerous.  I would have
preferred it if "foo" had stood for the array, and "&foo" had stood for the
address of the array (the '&' would remind the reader of the code that it was
indeed an address without relying on their contextual knowledge of C to
fill that detail in) and, using the statements in the previous example,
you could refer to "foo[5]" either as "foo[5]" or "(*bar)[5]" (or, as I
usually do in such circumstances, *(bar + 5)).  This would have no effect
in what computations could be expressed, nor would it have any effect on
how those computations were implemented (i.e., you wouldn't get further
removed from the machine), it would just be syntactic sugar.  As such,
it probably wouldn't have done any harm but also isn't worth doing at this
point given that it would change the rules in the middle of the game.

	Guy Harris
	{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guy