Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!nosc!ucsd!rutgers!cmcl2!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: portability Message-ID: <9449@smoke.BRL.MIL> Date: 20 Jan 89 15:16:02 GMT References: <16573@iuvax.cs.indiana.edu> <9419@smoke.BRL.MIL> <86097@sun.uucp> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 27 In article <86097@sun.uucp> swilson@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.