Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!uakari.primate.wisc.edu!aplcen!haven!adm!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.misc
Subject: Re: Answers, Chapter 1: TeX (was C's sins... and others)
Message-ID: <6363:Nov720:32:5090@kramden.acf.nyu.edu>
Date: 7 Nov 90 20:32:50 GMT
References: <7298:Nov620:50:5990@kramden.acf.nyu.edu> <5091@lanl.gov>
Organization: IR
Lines: 22

In article <5091@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
> From article <7298:Nov620:50:5990@kramden.acf.nyu.edu>, by brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
> > Huh? Pointers are used to track the segments. It's just that you never
> > try to use one pointer across segments. This sort of bi-level allocation
> > is actually rather easy. Pointers are perfectly adequate for writing the
> > _whole_ memory manager.
> Well, not on my PC at any rate.  Segments have a maximum size of
> 64K.  The memory is 640K.  Clearly, some arithmetic on numbers bigger
> than 16-bits is required to keep track of free space.  C pointers
> can't do that.  But, _something_ must be.  Must not be pointers though,
> all them use 16-bit arithmetic.

You are being illogical. ``Must not be arrays though, all them use
16-bit indexing.'' Just because arithmetic can't take pointers out of
their segments doesn't mean pointers are restricted to a single segment.

Perhaps it would help if you realized that a C pointer is an
abbreviation for a pointer to an array. When you index it, you are
(conceptually) dereferencing the pointer and then indexing into the
array.

---Dan