Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!necntc!cullvax!drw
From: drw@cullvax.UUCP (Dale Worley)
Newsgroups: comp.lang.c
Subject: 80*86 vs. C?
Message-ID: <1482@cullvax.UUCP>
Date: Fri, 21-Aug-87 13:20:19 EDT
Article-I.D.: cullvax.1482
Posted: Fri Aug 21 13:20:19 1987
Date-Received: Sun, 23-Aug-87 01:49:35 EDT
Organization: Cullinet Software, Westwood, MA, USA
Lines: 34

gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
> In article <2163@xanth.UUCP> kent@xanth.UUCP (Kent Paul Dolan) writes:
> >I don't think it is a useful endeavor to labor at such length to embed
> >the hardware design mistakes of the past in the C standards of the
> >future.
> Please explain how we're doing this.

I suspect that kent wants:

All addresses are pointers into an enormous, linear address space.
Thus, any two pointers can be subtracted, one can point off the
beginning or end of a malloc'ed section of memory, etc.

All addresses are byte-addressed, and are the same size and alignment
as ints.

One can dereference NULL.

etc.

These are the same complaints that are voiced here all the time,
usually in the form: "Lots of [bad] code depends on this, so it should
work."  It is best summarized by the phrase "idiots who think all the
world's a Vax".

C is (or should be) a high-level language.  Hardware architecture
shouldn't leak into the code one writes, at least when the code
conforms to an ANSI standard.

Dale
-- 
Dale Worley	Cullinet Software		ARPA: cullvax!drw@eddie.mit.edu
UUCP: ...!seismo!harvard!mit-eddie!cullvax!drw
OS/2: Yesterday's software tomorrow	    Nuclear war?  There goes my career!