A tale of two C's.

[Richard A. O'Keefe]

In article <4626 at ihlpf.ATT.COM>, nevin1 at ihlpf.ATT.COM (00704a-Liber) writes:
> >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.

> Yes, but there is nothing in dpANS which _requires_ this.  Nor do I think
> it should be required.

I did not say that the dpANS requires it, or that it should require it,
or that anyone should require it.  I merely outlined a scheme which _would_
make it safe for users to replace library facilities.  The scheme is nothing
more than good software engineering practice.  I don't know whether any C
implementation actually does that (at least the version of UNIX I'm using
doesn't have a hidden _malloc()).

> If a compiler writer decides to hand code in
> assembler all the library routines so that it produces the tightest,
> fastest possible code he should be allowed to do so. (in which case internal
> subroutines may only be assembler JMP statements which do not have nearly
> as much overhead as normal C function calls).

He should also be allowed to go broke.  I'd much rather he spent his time
figuring out how to make _my_ code go fast.  I would be _especially_
forgiving to a compiler writer who had decided to put the effort into making
normal C function calls fast.  [e.g. special treatment for leaf functions,
maybe even #pragma inline(...).]