Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!umd5!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: A tale of two C's. Message-ID: <7750@brl-smoke.ARPA> Date: 24 Apr 88 16:54:31 GMT References: <152@ghostwheel.UUCP> <7691@brl-smoke.ARPA> <154@ghostwheel.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 20 In article <154@ghostwheel.UUCP> ned@ghostwheel.aca.mcc.com.UUCP (Ned Nowotny) writes: >When portability is not an issue, a programmer should be free to use >his or her own implementation of a standard library function. I think you need to explain why this is considered desirable. Many of the library functions are likely to have secret internal interfaces to others, so you cannot implement them correctly in a portable application. Others, such as strcpy(), will be implemented more efficiently in general in the standard library than in your application. If you try to speed them up by providing subset functionality, you may break other library routines that need to use these with full functionality. Whenever the C library is inappropriate, you should code for the "freestanding" environment rather than the "hosted" environment. Then you can define almost all functions as you see fit without breaking anything. Of course you may wish to steal some functions from the hosted-environment library, but whether or not that will work depends on details of the specific implementation, among other things.