Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.society.futures
Subject: Re: C's sins of commission (was: (pssst...fortran?))
Message-ID: <63610@lanl.gov>
Date: 20 Sep 90 19:35:40 GMT
References: <9009201017.AA06087@rice-chex>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 112

From article <9009201017.AA06087@rice-chex>, by bson@AI.MIT.EDU (Jan Brittenson):
> 
>    So how would you propose to accomplish the following, for example,
> without pointers or pointer arithmetic?
> 
> 	1. Pointer range check (see if a buffer crosses page
> 	   boundaries, for instance).

Well, without pointers, why do you need a pointer range check?  Computing
the range of something that doesn't exist seems a little silly.

However, you parenthetical remark is of value - unfortunately, it's not
possible in _legal_ ANSI C.  Pointer arithmetic cannot be carried out past
the bounds of an individual object.  Pointers to different objects cannot
be subtracted or compared _legally_.  This is so that pointer arithmetic
operations can ignore the segment part of addresses on segmented machines.
So, you can't tell with C pointers whether your buffer crosses page
boundaries or anything because you can only compare the pointer _within_
the buffer itself - and you don't know the relative position of the
beginning of the buffer to page boundaries.

I think you had in mind casting the pointer to an int and looking at
the raw address - the ANSI standard leaves this process undefined.

Now, if you're talking about non-standard extensions to C which would
allow you to do this stuff - then any other language can contain the
same non-standard extensions.

> [...]
> 	2. Calculate physical addresses for DMA controllers.

Why should I care?  The system/environment should be able to give me the
address if I need it.  But, how do I use a raw address anyway? _Standard_
C pointers don't give me any such access.  Access to such things as
hardware controllers should be privilaged to the system - and _it_
can contain machine dependent code - like assembly.

> [...]
> 	3. Sort a linked list on addresses of some data pointed to
> 	   from within the node. Or to keep it sorted as new (addresses
> 	   of) data is added.

I guess you'll have to tell me how this differs from sorting on the
index of the data within an array or sequence.  Since the sequence is
dynamic, you can add all the elements you wish - and still sort on
index.  And, once again, the integer value of different pointers is
_not_ defined by the ANSI standard - nor it their relative order.

> [...]
> 	4. Implement malloc()/free().

When I found out that the ANSI C standard prohibited comparing/subtracting
pointers to different objects, I pointed out on comp.lang.c that malloc()
and free() could not not be written in _standard_ C.  They agreed with me.
I pointed out that the ability to use pointers as raw addresses was the
only thing of value that C pointers had (in my opinion).  They said I was
wrong for wanting it, I couldn't do it, that's that.  In fact, I'm on the
side of the rest of you who _want_ pointers to do raw address calculations
- C pointers don't.

> [...]
> 	5. Read and write addresses from/to pipes.

Again, standard C can't do this.  However, this is also something that
the system should provide a clearer, higher-level way to do.

> [...]
>    I wonder whether any compiler can be designed to successfully
> determine when to duplicate data and when to use a reference. As a rule,
> it's bad practise to duplicate data other than in the rare occasions when
> an explicit duplicate is needed.  [...]

It is even worse programming practice to alias data (by copying references)
other than those rare occasions when aliasing is a required part of the
algorithm.  Inadvertent aliasing leads to many man-hours of unnecessary
debugging time.

Besides, you aren't paying attention.  The list of data structures I
gave included an alias attribute.  Data types with the alias attribute
are assigned by copying the reference instead of the data.  Thus, the
programmer has explicit control over whether aliasing is allowed or not,
And, when it's not, the compiler can detect and signal an error when
the programmer inadvertently tries to do it.

> [...]
>    I'm curious as to why so many programmers engage themselves in hot
> debates over how to best implement strings. String processing is
> proportionally insignificant - the first thing done after a read is
> usually a tokenization, either through hand-written code or the output of
> a lexical front-end generator.  [...]

Tokens are also strings (which must be frequently compared and efficiently
stored).  Symbol tables also contain strings (among other stuff).  Text
processors usually don't have much data that isn't part of one string
or another.  This is a vital question to _some_ applications.  If it
isn't for you, so be it.  But don't question the need that others feel
for strings - they may know something about their application that you
don't.

> [...]
>    Just like some algorithms cannot be reasonably coded without gotos -
> the alternative would likely be even worse - some operations on data or
> certain functionality cannot reasonably be performed without pointers.
> [...]

I still you'd tell me what those applications are.  Absolute raw addresses
aren't even in C (though, I think that for the systems programmer, they
are absolutely necessary - not for anyone else though).  I'm still looking
for a _legal_ C application that can't be done with the 7 data structuring
tools I gave.

J. Giles