A tale of two C's.

[Karl Heuer]

In article <195 at sdeggo.UUCP> dave at sdeggo.UUCP (David L. Smith) writes:
>>In article <154 at ghostwheel.UUCP> ned at ghostwheel (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 don't see that there's any problem.  In K&R C, one can replace a library
function, and the result is not portable.  In ANSI C, this continues to be
true.  No doubt some vendors will continue to supply implementations which
will do what you expect even in the face of such a construct.

>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.

And it's a pain trying to port sh to implementations that don't conform to its
bogus assumptions.  I've been there.

>Doug mentions "hidden interfaces" between library routines.  These
>don't sound like a good idea and probably should be avoided.

Let's consider the simple kind of "hidden interface".  On one implementation,
printf() works by calling fputc().  On another, it doesn't.  Both are correct,
and hence the result of writing your own fputc() is undefined.  If you don't
like that situation, you'd have to specify which implementation is illegal.
This would be an otherwise-unnecessary restriction on the implementor, and I
don't think it's justifiable.

Karl W. Z. Heuer (ima!haddock!karl or karl at haddock.isc.com), The Walking Lint