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.