Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: Mark Williams C
Message-ID: <10388@smoke.BRL.MIL>
Date: 9 Jun 89 15:39:20 GMT
References: <24094@agate.BERKELEY.EDU> <431fba10.14a1f@gtephx.UUCP> <8137@boring.cwi.nl> <8530@chinet.chi.il.us> <13475@haddock.ima.isc.com> <1000@twwells.uucp> <13522@haddock.ima.isc.com> <1011@twwells.uucp> <8465@june.cs.washington.edu> <10334@socslgw.csl.sony.JUNE
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 15

In article <1188@cbnewsc.ATT.COM> nevin1@ihlpb.ATT.COM (nevin.j.liber) writes:
>Does this mean the ANS C v2 won't have any new keywords??  I doubt it.

Certainly, adding keywords risks breaking code that used them as identifiers.
I don't envision keywords being added, although something like "noalias" might
be adopted for __STDC__==2.

>As a matter of fact, There is terribly little that can be added to C which
>will not break existing pANS C v1 code ...

Several vendors have found conforming ways to extend the language
specified by Standard C.  Other ways one might think of currently
require a diagnostic, which does not pose a compatibility problem
were the current constraints to be relaxed.  GCC supports several
such syntactic extensions.