Path: utzoo!attcan!uunet!lll-winken!ames!haven!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn ) Newsgroups: comp.std.c Subject: Re: portability Message-ID: <9508@smoke.BRL.MIL> Date: 26 Jan 89 23:02:23 GMT References: <16573@iuvax.cs.indiana.edu> <9419@smoke.BRL.MIL> <86097@sun.uucp> <877@auspex.UUCP> <23254@watmath.waterloo.edu> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 33 In article <23254@watmath.waterloo.edu> rbutterworth@watmath.waterloo.edu (Ray Butterworth) writes: >It seems to me that every implementor of a library other than >the Standard C library is going to need a means of having >alternate names for its functions (unless none of them call >each other). I disagree with this. Generally, one takes a library (for example, a "graphics library") as a package, and assumes that everything defined in the manual for it is reserved if the library is used at all. In effect, ANSI C does this for the standard C library in a hosted implementation; although there can be extra stuff in there, in effect it has to be isolated into what amounts to a different package from the standard C routines. C could obviously use some formal notion of packages, and extensions such as C++ do provide this. Meanwhile, providers of C support packages of all kinds are well advised to use some sort of package prefix naming scheme such as recently discussed in comp.lang.c, so that various packages can be used together without interference. >I don't understand why the C Standard didn't require, or at least >suggest, some such standard mechanism. Because such implementor-provided libraries are outside the scope of the Standard. The C Standard itself requires, it does not suggest; and there is no way for it to impose requirements on things unrelated to the specifications in the Standard. There would be no way that such a constraint could be verified, for example, as part of product acceptance testing against procurement specifications. That doesn't mean that most or all of X3J11 wouldn't agree that it is desirable for "add-on" packages to do something to keep their own name spaces in order.