🚀 go-pugleaf

From article <1990Apr9.144123.13017@maths.nott.ac.uk>, by anw@maths.nott.ac.uk (Dr A. N. Walker):
> In article <14304@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
> [... (p + largeint) - largeint ==0 ...]
->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?

I should rephrase.  The above will work on all implementations that I'm aware
of.  Further, I see no reason for the language definition not to _require_
that the above identity be true.  If there is such a reason, you should
enlighten me instead of just claiming that I'm wrong without evidence.

> [...]
->			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.  [...]

Perhaps you should get together with the other posters to this net in order
get your stories straight.  Others are claiming that keeping the pointer
as a 3-tuple is a correct implementation of C pointers.  You are claiming
that the pointer is to a single element (so any auxilliary bound information
is innappropriate).  I would agree with your interpretation that a pointer
is an address of a single object.  Pointer arithmetic allows you to move
to the next address (or, by scaled arithmetic, the address after the current
object).  If this next address is not in range, the only constraint should
be that you must not dereference the pointer.  The same goes whether you
increment the pointer by one or by 'largeint'.

> [...]      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.

I agree.  But here you are referring to _arrays_ not pointers, and your
syntax reflects that fact.  In C (with the appropriate changes in
declaration), it is not only _allowed_ to refer to *(sa+15), it is 
common practice.  In fact, there is no way to limit the 'bound' of the
pointer to anything less than all of array a.

> [...]
->				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, [... ie. "for(p=a,p<a+n,p++);" ...]

What 'zillions' of lines were examined, I wonder?  Certainly not much
scientific code.  If you are doing, say, tensor calculations, you often
need to break into column vectors one place, row vectors in another, and
the diagonal in still another.  Computing arrays with stride is a _very_
common occurance.  That's why vector machines usually have stride built
right into the hardware.

> [...]
->	     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.

No.  I don't claim that.  I am willing to give latitude to language
design problems.  But, after 18+ years of evolution (not all of it
backward compatible) there seems to have been plenty of time to correct
the design before ANSI set it into concrete.  Further, this is
comp.lang.misc - we should not lightly assume that C mistakes won't
be carried into the future in other designs.  It is by discussing
them critically and publicly that future language designers can
learn by the mistakes of the past.

J. Giles