Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!kl-cs!nott-cs!piaggio!anw
From: anw@maths.nott.ac.uk (Dr A. N. Walker)
Newsgroups: comp.lang.misc
Subject: Re: JLG's flogging of horses (was Re: Relationship between C and C++)
Message-ID: <1990Apr9.144123.13017@maths.nott.ac.uk>
Date: 9 Apr 90 14:41:23 GMT
References: <MEISSNER.90Apr5115933@curley.osf.org> <14304@lambda.UUCP>
Reply-To: anw@maths.nott.ac.uk (Dr A. N. Walker)
Organization: Maths Dept., Nott'm Univ., UK.
Lines: 60

In article <14304@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
>Maybe not in C.  Actually, if pointer arithmetic is carried out as integer
>modulo 2^n (like most implementations), then the above expression _is_
>guaranteed to give p.

	What is the difference between "in most implementations, this is
guaranteed to work" and "this is not guaranteed to work"?  Isn't this the
whole portability issue?

>			However, you missed my point.  Suppose you have
>a large array and you alias *p to a small section of it.  In this case,
>incrementing p past the end of the data it points to is still appropriate.

	"*p" aliases just one element, so the point seems to betray a
confusion.  If you select a slice of an array [not a C construct, of
course], then going out of bounds on that slice is, and should be,
still an error:  eg in Algol, after

	[100] int a;
	ref [] int sa = a[10:20];

then "a" is an array with elements a[1], ..., a[100];  "sa" is a slice of
"a" with elements sa[1], ..., sa[11] and sa[1] aliassed to a[10], etc.
Referring to sa[0] or sa[12] is, and should be, simply an error;  if you
wanted "sa" to be larger, you should have declared it that way.

>Why the special dispensation?

	Historical necessity, caused by the prevalence of code like

		for (pa = a; pa < a + SIZE; pa++)
			...;

Such code used to be technically illegal, and some of us avoided it, but
it was too common to be ignored, and too convenient, so it was legitimised.

>				And why just _one_ element past the end?
>Why not N elements past - or is processing arrays with _stride_ something
>C doesn't do?  Why not have a dispensation for addresses before the start
>of the array - or is processing arrays in reverse order something C doesn't
>do either?

	Because (a) on looking at zillions of lines of code, virtually
everything fell into the above paradigm, and the other cases you mention
just didn't happen in practice -- if you scan an array backwards, you tend
to test against "a" rather than against "a-1", so that code is legal;
(b) the cost is ensuring that just one byte past "a" is still a legal
address to the operating system, whereas any further extension requires
at least one further virtual element, which may easily be rather large;
and (c) if you think that a zero-sized array is legal, you get the chance
of a legal pointer to it -- this is a murky area in both C and Algol.

>	     No, to be consistent with your suggested constraint on pointer
>arithmetic, there should be no dispensations at all [...]

	Agreed;  we should all design perfect languages first time.

-- 
Andy Walker, Maths Dept., Nott'm Univ., UK.
anw@maths.nott.ac.uk