Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!iuvax!pur-ee!a.cs.uiuc.edu!uxc.cso.uiuc.edu!uxe.cso.uiuc.edu!mcdonald From: mcdonald@uxe.cso.uiuc.edu Newsgroups: comp.lang.c Subject: Re: Leo's ANSI C Flame Message-ID: <225800045@uxe.cso.uiuc.edu> Date: 13 Jul 88 14:11:00 GMT References: <2258@sugar.UUCP> Lines: 23 Nf-ID: #R:sugar.UUCP:2258:uxe.cso.uiuc.edu:225800045:000:1016 Nf-From: uxe.cso.uiuc.edu!mcdonald Jul 13 09:11:00 1988 >>and with, probably, a bit of name-space pollution. >Whatever for? It's simple enough to avoid. Backward compatibility. Buyers will scream bloody murder if a vendor's new compiler won't compile programs their old one did. Remember memmove. >>Most compilers will require a special command line switch to get full >>compatibility with the standard. >I think I'd make full ANSI the default, and have a special command-line option >to get bug-for-bug compatibility (e.g. Reiser cpp). Perhaps you mean that >most compilers will require a special option to disable all extensions and >compile only strictly conforming programs? This is exactly what I meant. I am of the understanding that it will be very difficult to come up with "conforming" extensions other than by adding functions that begin with an underscore. Do you mean to say that, for example, added keywords like "far" or "near" or "asm" or "pascal" will be allowed? If Microsoft removed these, their sales would drop to zero overnight. Doug McDonald