🚀 go-pugleaf

In article <5006@scolex.sco.COM> seanf@sco.COM (Sean Fagan) writes:
>In article <16021@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes:
>>In article <1990Feb23.184656.3110@siia.mv.com> drd@siia.mv.com (David Dick) writes:
>>>Remember that you can no longer "roll your own" [standard library routine]
>>You never could.
>
>Huh?  Since when?  You could always write your own strcpy (although things
>might not have worked)

I think you've just made my point.  The old rule was: you can try to write
your own malloc(); it might work or it might not.  If you know enough about
the internals of the implementation, you can probably write one that works.
(After all, the library itself is largely written in C.)

The new rule is: you can try to write your own malloc(), but the result is
officially undefined--meaning it might work or it might not.  If you know
enough about the internals of the implementation, you can probably write one
that works.

>Since strcpy may not even *be* in the library, just in the compiler, that
>makes it kinda hard to write your own.

Even if it's a builtin, there has to be a spare copy in the library so that
you can take its address%.  (This is new to ANSI C; pre-ANSI C commonly
implemented some routines as macros without providing a function version.)

Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint
________
% With a few minor exceptions (assert(), setjmp()).