portability

[Doug Gwyn]

In article <86097 at sun.uucp> swilson at sun.UUCP (Scott Wilson) writes:
>Excuse my ignorance but the radio's turned up too loud.  What happens
>to the names of routines used to implement standard library functions?

Functions specified in the Standard may safely be used in implementing
other functions in the Standard library.  Other external identifiers
must be taken entirely from the name space reserved for implementations.

>For example can a pANS program with a routine called write() reliably
>be compiled and run on a UNIX system without causing printf (really
>_flsbuf) to call the user's routine and botching everything?

Yes; that is exactly the point of the prohibition against conforming
implementations infringing on the name space reserved for applications.

>Does _flsbuf need to be rewritten to call __write() ...

Yes, but your example wasn't the right way to do that.  "__write" is
best made an assembly-coded system-call hook just like the current
"write".  The current "write" function can remain in the UNIX C library,
but it must not be used in implementing the C language run-time support
(don't laugh! We have a compiler that generates calls to "bcopy"), nor
within the implementation of library functions specified in the Standard.

I think UNIX/POSIX C implementors have been aware of this for quite
some time.  It has no adverse impact on existing applications, and is a
necessary constraint to achieve maximal program portability.