Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!bloom-beacon!bu.edu!mirror!ima!haddock!karl From: karl@haddock.ima.isc.com (Karl Heuer) Newsgroups: comp.std.c Subject: Re: Naming Message-ID: <16095@haddock.ima.isc.com> Date: 6 Mar 90 00:01:07 GMT References: <1990Feb23.184656.3110@siia.mv.com> <16021@haddock.ima.isc.com> <1990Feb28.221425.6430@siia.mv.com> <1990Mar2.172503.1567@utzoo.uucp> <12273@smoke.BRL.MIL> Reply-To: karl@haddock.ima.isc.com (Karl Heuer) Organization: Interactive Systems, Cambridge, MA 02138-5302 Lines: 13 In article <12273@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >To be fair, it should be noted that the absence of any clear statement >about the validity of supplanting library functions with one's own made >it uncertain whether it was supposed to be allowed or not... Actually, I was thinking more along these lines: whether or not it was *supposed* to be allowed, in actual practice it was not. For example, on most Unix systems, if you try to provide an alternate version of malloc() without also providing realloc() and free(), you'll get an error at link time, since the three functions are all in the same module. Thus, arbitrary library substitution does not always work. Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint