portability

[Doug Gwyn]

In article <23254 at watmath.waterloo.edu> rbutterworth at 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.