Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: Answers, Chapter 1: TeX (was C's sins... and others)
Message-ID: <5347@lanl.gov>
Date: 8 Nov 90 19:40:26 GMT
References: <7AZ6O15@xds13.ferranti.com>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 31

From article <7AZ6O15@xds13.ferranti.com>, by peter@ficc.ferranti.com (Peter da Silva):
> [...]
> Let me guess... you have an IBM-PC at home? Well, *THAT* is the machine
> responsible for the ANSI restrictions on pointers *in portable code*.
> 
> I rest my case (good thing, it was getting pretty heavy).

I know the IBM-PC is the cause of the ANSI restriction.  That was
the gist of my complaint against ANSI.  They let a few bad IBM-PC
implementations dictate a rule which makes it impossible to rely on
pointers to do memory management implementation.  There is no reason
for the rule except to include these laze compilers into the class
of "standard conforming" C compilers.  Even on a PC, it's possible
to implement pointers so that they can be compared no matter where
they point (it just means that pointer compares are a little
slower).  This should have been required by the standard.

By the way, Peter da Silva also points out that memory managers are
machine dependent anyway (so it's alright for them to be in assembly
I guess is his conclusion).  This is true to a very small extent.
I've seen memory managers which work well on large numbers of
different types of hardware but are written in high-level languages.
The machine dependence usually takes the form of a few parameters
which specify whether memory is byte/word addressible, how big
memory is, and a few other simple things.  If the C standard had
required pointer comparisons to _always_ be reliable, a portable
memory manager of this kind could easily be written in C for nearly
every machine I've ever seen.  As I say, this is one of the few
things that I think pointers really _are_ suited to.

J. Giles