Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!tut.cis.ohio-state.edu!mailrus!uflorida!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: Mark Williams C
Message-ID: <10378@smoke.BRL.MIL>
Date: 7 Jun 89 21:55:08 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: 10

In article <10334@socslgw.csl.sony.JUNET> diamond@csl.sony.junet (Norman Diamond) writes:
>Your code will break in newer versions [of standard-conforming C
>compilers] anyway.

Standard-conforming code is not expected to be rendered non-conforming
in the next revision of the C Standard.  Any area where there was some
sentiment that it might was flagged as an "obsolescent feature" in the
current Standard, which should serve as sufficient warning to people
to avoid relying on their long-term stability.  All other features
should remain in C "forever".