A tale of two C's.

[William E. Davidsen Jr]

In article <195 at sdeggo.UUCP> dave at sdeggo.UUCP (David L. Smith) writes:
>In article <7750 at brl-smoke.ARPA>, gwyn at brl-smoke.ARPA (Doug Gwyn ) writes:
>> In article <154 at ghostwheel.UUCP> ned at 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 

  I proposed to dpANS that the library be broken into "sections" which
were independent.  That is you could assume that anything in one section
used only documented calls to anything in another section, but there was
an assumption that if you changed anything in one section that you might
have to replace all of it.

  As I recall I wanted to separate the math, io, and a few other
sections. I don't remember the discussion, but the idea was not adopted
at that time.

  My desire is to replace print with something which doesn't take up a
lot of space for F.P. routines if I will call it only with integers.
Suggestions to the contrary, this would reduce the size of the program,
and putting in explicit error messages would make it grow as large as
the math routines (in many cases).

  I just renamed my routine and use a
	#define print my_print
to generate the calls. This leaves the code easily portable.
-- 
	bill davidsen		(wedu at ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me