Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ucsd!sdcsvax!ucsdhub!jack!sdeggo!dave
From: dave@sdeggo.UUCP (David L. Smith)
Newsgroups: comp.lang.c
Subject: Re: A tale of two C's.
Message-ID: <195@sdeggo.UUCP>
Date: 25 Apr 88 18:03:24 GMT
References: <152@ghostwheel.UUCP> <7691@brl-smoke.ARPA> <154@ghostwheel.UUCP> <7750@brl-smoke.ARPA>
Organization: Lazy Programmer's Society of San Diego
Lines: 44

In article <7750@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
> In article <154@ghostwheel.UUCP> ned@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.

The one that I have seen most commonly is a replacement malloc() 
routine.  For example, the Bourne shell replaces malloc() with its 
own version so that it can have a stack interspersed with the heap.

Whether or not this was necessary I'm not sure, but it does seem 
like the easiest way to implement it.  The stack is set at the top 
of memory; when it grows to big it generates a segmentation violation 
which causes malloc() to allocate more memory and relocate the stack 
at the top of memory.  The other alternative, if implemented with 
vanilla malloc, would be to give some memory to the stack and then 
monitor it everytime something was put on the stack to make sure it 
didn't overflow.  Relying on the system to tell you when you're
out of space is a lot easier.

The Bourne shell's malloc() also provides a good reason not to 
replace library routines with your own lightly.  In at least one 
version of sh (I believe it is the V.2 version), it doesn't work 
quite right.  If this malloc() package had been used more extensively 
(as the library routines are) this bug wouldn't have existed for long.  
(BTW, the Celerity version of sh has this fixed, plug, plug :-) )

Doug mentions "hidden interfaces" between library routines.  These 
don't sound like a good idea and probably should be avoided.  After 
all, occasionally library routines have bugs in them which the vendor 
is unwilling or unable to fix.  A binary-license site with a smart 
programmer can come up with a functional replacement for a library 
routine, sans bug, but not if these hidden interfaces exist.

In short, I feel that being able to replace library routines is 
necessary for two reasons:  To achieve a difference in functionality 
without recoding the rest of the library routines which depend on the 
one you want to change and to fix bugs when you don't have a source 
license.
-- 
David L. Smith
{sdcsvax!jack,ihnp4!jack, hp-sdd!crash, pyramid, uport}!sdeggo!dave
sdeggo!dave@amos.ling.edu 
Sinners can repent, but stupid is forever.