A tale of two C's.

[David R. Stampf]

In article <7750 at brl-smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <154 at ghostwheel.UUCP> ned at 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.
>

Even when portability is and issue - I think that the C view of libraries
is meant to be taken advantage of!

I have frequently found the need to chuck some of the standard library
routines in favour of locally written routines - more often that not, these
are the memory allocation routines.  Sometimes it is to gain a *huge*
performance gain (in one example I didn't need the full generality that malloc
gave me, since I was always allocating fixed length blocks, so I wrote my own
that took advantage of the machine that I was running on (Mac) and other times
it is to take advantage of some unique aspect of the machine that I was working
on (parallel processing with shared memory).  In either case, I wanted the
code to be portable to { wide variety of machines that may have very different
architectures.  Those machines may pay a performance penalty, but not the
ultimate penalty of having to rewrite bizarre library routines.

In these cases, you cannot export your custom library routines - but have to
allow the default library to kick in.  (It also makes debugging a *lot*
easier in most cases).

	< dave.