Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!purdue!ames!uhccux!munnari.oz.au!mimir!hugin!augean!idall From: idall@augean.OZ (Ian Dall) Newsgroups: comp.lang.c Subject: Re: effect of free() Message-ID: <572@augean.OZ> Date: 23 Aug 89 04:20:36 GMT References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU> <320@cubmol.BIO.COLUMBIA.EDU> <3777@buengc.BU.EDU> <1989Aug17.005548.745@twwells.com> <568@augean.OZ> <14343@haddock.ima.isc.com> Organization: Engineering Faculty, University of Adelaide, Australia Lines: 47 In article <14343@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: >In article <568@augean.OZ> Ian Dall writes: >>In article <1989Aug17.005548.745@twwells.com> bill@twwells.com (T. William Wells) writes: >>> free(ptr); >>> if (ptr == 0) ... >>>The if might cause a trap when the value of ptr is accessed. >The issue is not whether the value of ptr has changed. Some architectures >distinguish between arithmetic registers and address registers, and refuse to >allow arbitrary garbage to be loaded into an address register. "free" or ANY function cannot change it's argument. "free" should not load anything into "the special address register" (let alone "arbitrary garbage"). >>The compiler doesn't know what malloc and free do. For all the >>compiler knows malloc and free could be functions you wrote with >>completely different semantics. > >That's implementation-dependent. For all you know, malloc() and free() are >builtins on my compiler. Your compiler can define any builtins it likes, but if they don't work like real functions they haven't been done properly. I don't have a copy of the ANSI standard, but surely any specification of the behaviour of standard fuctions is to be read in conjunction with the defined behaviour of ANY function. Which is call by value. i n e w s f o d d e r -- Ian Dall life (n). A sexually transmitted disease which afflicts some people more severely than others. idall@augean.oz