Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: 80*86 vs. C?
Message-ID: <6293@brl-smoke.ARPA>
Date: Wed, 19-Aug-87 20:54:26 EDT
Article-I.D.: brl-smok.6293
Posted: Wed Aug 19 20:54:26 1987
Date-Received: Sat, 22-Aug-87 06:14:43 EDT
References: <166@qetzal.UUCP> <157@hobbes.UUCP> <875@bsu-cs.UUCP> <1219@cognos.UUCP> <25173@sun.uucp> <298@apex.UUCP> <2163@xanth.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 16

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 don't recall anything
in the draft proposed American National Standard for C that is
present solely because of segmented architectures.  Certainly
not the requirement that no data object be given an address
indistinguishable from a null pointer; that constraint is
logically necessary and has been with us for a long time.

Undoubtedly there are some 80*86 compilers that purport to be
C compilers but do not correctly implement anything that could
reasonably be called "C".  I suggest not buying them (even
better, let the vendors know why you don't buy such products).