using standard interfaces

Richard Harter g-rh at cca.CCA.COM
Mon Sep 19 06:35:44 AEST 1988


In article <1988Sep17.211053.8712 at utzoo.uucp> henry at utzoo.uucp (Henry Spencer) writes:
>In article <33391 at cca.CCA.COM> g-rh at CCA.CCA.COM (Richard Harter) writes:
>>This sounds good, but there is a problem to take into account.  If
>>you have your own routine with the same name as the "standard"
>>routine there is the potential for problems when you port into
>>a system that has the "standard" routine in its library...

>This just means that inclusion of the routine in question must be optional,
>so it can be disabled on such systems.  No big deal.  Possibly the best way
>to do this is to #ifdef the user-supplied routine, so that an explicit -D
>option (or whatever) is required to use it.

No big deal for me -- I roll my own and use different names, so I don't
have any problems.  I don't need surprises like finding that my version
of a routine breaks the system because there is a system routine with the
same name (and nominal effect) that has side effects that the system relies
on.  It may be that there are no such routines in any of multitude of systems
that I maintain code on.  Given the eccentricities of some of the
implementations out there I have my doubts.  Given the choice between not
having the problem in the first place, and discovering the hard way during
porting that I have to remove my copy of the routine in question, my
choice is clear -- life is too short to solve unnecessary mysteries.
(I also don't want to spend the time and effort of keeping track of 
which routines are available in which releases of different operating
systems, except when absolutely necessary.) However I grant that my
views are dictated by my particular requirements.
-- 

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
	Richard Harter, SMDS  Inc.



More information about the Comp.lang.c mailing list