Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!uunet!twwells!bill From: bill@twwells.com (T. William Wells) Newsgroups: comp.lang.c Subject: Re: effect of free() Message-ID: <1989Sep28.101227.9645@twwells.com> Date: 28 Sep 89 10:12:27 GMT References: <319@cubmol.BIO.COLUMBIA.EDU> <165@bbxsda.UUCP> Organization: None, Ft. Lauderdale, FL Lines: 73 In article <165@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes: : Someone whose name I keep losing writes: Me. Bill Wells. : For some reason, everytime : I try to followup one of your postings my 'rn' program aborts back to : the shell. This happens only with your postings (???). I doubt it. The problem is probably with the long References: line. My system, since I'm running C news, generates these looooong message ids which quickly result in an oversized References: line. I'm going to edit that line in this message, I'll bet you can follow up now. : >You missed the point. I did *not* say that my programs never : >referenced a pointer after it was freed. Don't I wish. What I'm saying : >is that I never *designed* a program to do that. : : Then we are in agreement. How would you feel, then, if your ported : your code to some machine that wasn't so forgiving; and when you : complained, someone told you that you were lazy and shouldn't have : written the code that way in the first place? None of us want to : pay so dearly for something so trivial whether we intended it or : not. Remember, we're talking about more than free() calls here. I'm not sure what you are talking about. The original posting in this thread (mine) said that the C standard permits the compiler writer to assume that you don't use a pointer after a free, and thus he can have the compiler generate code that trashed the pointer value after the free. If I write the program so that it is not designed to reference pointers after they are freed, assuming I get it right, it doesn't matter whether the generated code trashes the pointer. If I get it wrong, I have a bug, which I should assume will show up sooner or later (a day later after the cost of fixing it goes astronomical :-), and it still doesn't matter whether the compiler does this. Actually, it does, a little: if in the compiler's C model freed pointers still have valid values, my error won't cause the program to violate that model immediately. But if the code does trash the pointer, my error makes the program violate its model, such programs are generally harder to debug. That is one of the reasons why, if I do have a compiler that generates this kind of code, I'd like to be able to turn it off. Of course, turning off optimizations is often a good idea when debugging, anyway. On the other hand, if I write my code assuming that the value of a freed pointer doesn't get trashed, I'm OK on "normal" compilers (if I'm reasonably careful, there are still things that will break even on those), but I've a big loser if I port the program to one that does this optimization. The conclusion is that I should avoid referencing the pointer after it is freed, so that this perfectly legit optimization won't break my code. Also, as I've implied elsewhere, there is a much better reason than this for not touching the pointer after it is freed: *conceptually*, once a pointer is freed, its value is meaningless. Pointers (other than null pointers) have meaning only insofar as they have an object at the other end. : BTW: Since I am having so much trouble with your postings (not : me personally :-) but 'rn' is having trouble.) I will have to : avoid further followups. If we have more to discuss let's try : e-mail. Let's see if this fixes the problem. --- Bill { uunet | novavax | ankh | sunvice } !twwells!bill bill@twwells.com