Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!apple!gem.mps.ohio-state.edu!ginosko!aplcen!unmvax!pprg.unm.edu!topgun.dspo.gov!lanl!cmcl2!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn) Newsgroups: comp.lang.c Subject: Re: reserved names (was: Weird problem with C compiler under SCO) Message-ID: <11181@smoke.BRL.MIL> Date: 28 Sep 89 21:23:29 GMT References: <71@promark.UUCP> <14561@bloom-beacon.MIT.EDU> <940@bbx.UUCP> <11157@smoke.BRL.MIL> <597@crdos1.crd.ge.COM> Reply-To: gwyn@brl.arpa (Doug Gwyn) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 10 In article <597@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: >What is not in the standard is any statement like "no future standard >library calls will have external names which ... Of course not. There is no way that this Standard can constrain future standards. The best we can do is indicate intended "Future Directions" as a guide to programmers and implementors concerning what to be wary of even though it's specified a certain way by the current Standard. But it is not the intention that any follow-on C language standard usurp more name space than we've already specifically set aside.