Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!mips!apple!bionet!agate!ucbvax!bloom-beacon!snorkelwacker!spdcc!ima!haddock!karl From: karl@haddock.ima.isc.com (Karl Heuer) Newsgroups: comp.std.c Subject: Re: Naming Message-ID: <16059@haddock.ima.isc.com> Date: 1 Mar 90 01:22:33 GMT References: <1990Feb23.184656.3110@siia.mv.com> <16021@haddock.ima.isc.com> <5006@scolex.sco.COM> Reply-To: karl@haddock.ima.isc.com (Karl Heuer) Organization: Interactive Systems, Cambridge, MA 02138-5302 Lines: 29 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()).