Path: utzoo!mnetor!uunet!lll-winken!lll-tis!mordor!sri-spam!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: A tale of two C's.
Message-ID: <924@cresswell.quintus.UUCP>
Date: 2 May 88 22:58:56 GMT
References: <152@ghostwheel.UUCP> <7691@brl-smoke.ARPA> <154@ghostwheel.UUCP> <488@sas.UUCP>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 19

In article <488@sas.UUCP>, bts@sas.UUCP (Brian T. Schellenberger) writes:
> First of all, it is clearly unportable and dangerous to replace the versions
> of the library routines used by other library routines...
Sometimes that is exactly what you want.  For example, what is the good of
replacing the malloc() family by something with the same interface but a
much better implementation if this doesn't catch malloc() calls from stdio?
If you _don't_ want to catch library calls, there isn't any need to 
REdefine any library function.  But yes, it is non-portable, and can be
dangerous (it's usually ok under UNIX and more trouble than it's worth under
VMS).

It's worth noting that exactly this technique is an offical part of the
System V library interface (see 'matherr').

A library _could_ be structured into "facilities" (malloc, stdio, math,
signal&longjmp, ...) such that each facility was defined to use only the
public interface of the other facilities.  It would then be safe to
replace an entire facility with your own code.  There is nothing in the
dpANS to prohibit a vendor doing this; code which relied on a well-structured
library would be non-portable but no longer dangerous.