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: <931@cresswell.quintus.UUCP>
Date: 5 May 88 08:02:08 GMT
References: <152@ghostwheel.UUCP> <7691@brl-smoke.ARPA> <154@ghostwheel.UUCP> <4626@ihlpf.ATT.COM>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 25

In article <4626@ihlpf.ATT.COM>, nevin1@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(...).]