Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!mit-eddie!bbn!uwmcsd1!ig!agate!pasteur!ames!mailrus!nrl-cmf!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: comp.lang.c
Subject: Re: trigraphs in X3J11
Message-ID: <8011@brl-smoke.ARPA>
Date: 4 Jun 88 21:15:52 GMT
References: <5215@ico.ISC.COM> <1490@eneevax.UUCP> <1988May23.000451.751@utzoo.uucp> <5391@ico.ISC.COM> <8805261740.AA00659@explorer.dgp.toronto.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) )
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 22

In article <8805261740.AA00659@explorer.dgp.toronto.edu> flaps@dgp.toronto.edu (Alan J Rosenthal) writes:
>Or, to put it another way, I fully expect all ansi-conforming compilers
>to come in two flavours:  a strictly conforming one and a useful one.

I've already demonstrated that trigraph mapping is virtually a non-problem,
since accidental trigraph sequences in existing code are quite rare.

As long as we're guessing about the future, what I expect to see on many
systems is a choice (perhaps via "switches", more usefully just as a
separate name for the compile command) between
	(a) backward-compatible C, probably with most of the newer
		non-conflicting Standard C features
and	(b) fully-conforming Standard C.

A vendor who tries to modify (b) to provide the vendor's notion of what
is "useful" will not be selling any compilers to me, since I will need
full (b) for my strictly conforming applications.  That is what having
a standard is all about.

The main reason for (a) on UNIX systems would be to support Reiser cpp
abuse, which many programmers have been guilty of.  Otherwise, Standard
C is pretty much upward compatible with old Random C.