Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!uwm.edu!rutgers!cmcl2!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn) Newsgroups: comp.lang.c Subject: Re: Weird problem with C compiler under SCO - I can't believe it! Message-ID: <11157@smoke.BRL.MIL> Date: 27 Sep 89 21:55:28 GMT References: <71@promark.UUCP> <14561@bloom-beacon.MIT.EDU> <940@bbx.UUCP> <534@crdos1.crd.ge.COM> Reply-To: gwyn@brl.arpa (Doug Gwyn) Distribution: na Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 22 In article <534@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: >Another thing which was left out of the ANSI standard is some name space >reserved to the user. As you state it, it's simply not true. ALL identifiers not specifically flagged as "reserved" (for the implementation) by the Standard are reserved for the (application) program's use. We staked out whole categories of name space such as is*() for use in future C standards. It is of course up to future C standardization committees to decide whether or not to turn "foo" into a keyword. You can expect that they will have to think even harder than X3J11 about compatibility problems caused by glomming onto previously program-available name space. The other problem you mention, of vendor-supplied libraries clashing with application (or other libraries) use of identifiers, is a real one. An approach like Xlib's (where all its identifiers start with a special reserved pattern "X") is viable, absent support for genuine "classes" or "packages". I would however recommend that more than one character be used for the package-specific prefix. We use two (Xx format) for our internal multiple-package projects, but it may take more to deal with a large raft of vendors.