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.