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.