🚀 go-pugleaf

In article <14327@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
>You have 'demonstrated' no such thing.  You have proposed an implementation
>which would _make_ my first statement false.  You have asserted (perhaps
>correctly) that the new C standard actually supports your interpretation.
>However, you have _NOT_ demonstrated that pointers which obey bounds are
>more general that arrays (they aren't).

Pointers can still be assigned to, and thus point to or into different
arrays or structures at different times. Arrays can't. Just because you
have bounds in the pointers, doesn't mean that a particular pointer
variable has to contain the same bounds at every time.

> You have _NOT_ demonstrated that pointers  _should_ obey bounds.

Of course they "should". At least the C standard explicitely leaves
room for bounds checking. You are not required not to check bounds.
Thus, you may choose freely whether to do it or not. If you like
bounds checking in general, naturally you want it on pointers too.

>In fact, what you are recommending is a constraint on pointers which
>removes one of the _only_ features that I thought pointers were useful
>for.

I don't know what you are thinking of here. If it is possible for pointer
variables to point at different objects at different times, and there is
a mechanism for obtaining pointers with smaller bounds from pointers with
larger bounds, for instance some kind of casting, I can't imagine what
more you could posible desire.

>  I already had a pretty low opinion about the value of pointers
>and you are busy destroying what respect I had left.  If it is your
>intent to make pointers seem _less_ useful than they might be, you
>are succeeding.

It seems to me that here, you are fooling yourself somehow. Either you
had unrealistic views of how pointer could be used, to start with (but
I haven't seen any other evidence for that), or you are somehow
misinterpreting the effects of putting bounds into the pointers.

>main(){
>       int A[10][20];
>       ...
>       sub1(A);
>       ...
>}
>       sub1(pa)

>Actually, of course, C has no way of doing this.  The procedure can't
>find out the dimensions of the argument.  And even if I were to pass
>the values 10 and 20 as separate arguments, the C declaration rules
>would not permit me to declare 'pa' as "int pa[bnd1][bnd2]".

Doesn't GNU C allow that kind of variable declarations? Ok, they're not
allowed by the C standard, but there's no inherent difficulty in adding
them.

>No, 'pa' is isomorphic to a one-dimensional array with bound 10*20==200.
>You can move 'pa' around linearly by adding and subtracting to it, but
>you can _never_ double subscript it.

As has been pointed out, it's never been a problem to double subscript
function arguments, if you declare them like arrays with constant sizes,
and expanding the language to allow variable sizes wouldn't change the
pointer concept of C in the least, thus this particular point is not
inherent to pointers. Maybe we should try not to confuse the general
usefulness of pointers and what particular features for using pointers
are included in the C-standard at one particular moment in time.

Also, when you for instance say that C should be changed to include
real arrays rather than bounds-checking pointers, don't you rather
mean _non-aliased_ and constant references (whether arrays or pointers
acting as arrays) ? Just because aliased arrays are disallowed in Fortran,
does that make non-aliasing an inherent feature of arrays? Isn't
this, again, confusing arrays with rules that apply to arrays in
one (or several) particular language?

Why don't you simply say that you'd like C to include non-aliased
arrays, to be able to optimize the particular kind of applications that
you are involved in, and leave it at that, rather than saying that
pointers are bad and C is bad and Fortran or anything else is better.
Can't we just agree that C and Fortran have radically different
historical backgrounds?

I'd say that on many points you are technically right in what you say,
except, sometimes, about C details, but your _perspective_ is what
upsets most people. The views about what is important in a particular
language, what is useful, what should be required by every language
regardless of background, and so on.

-- 
Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden
Phone: +46 19-13 03 60  !  e-mail: ske@pkmab.se
Fax:   +46 19-11 51 03  !  or ...!{uunet,mcvax}!sunic.sunet.se!kullmar!pkmab!ske