A tale of two C's.
Richard A. O'Keefe
ok at quintus.UUCP
Tue May 3 08:58:56 AEST 1988
In article <488 at sas.UUCP>, bts at 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.
More information about the Comp.lang.c
mailing list