Path: utzoo!attcan!telly!lethe!torsqnt!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn) Newsgroups: comp.lang.c Subject: Re: effect of free() Message-ID: <11131@smoke.BRL.MIL> Date: 22 Sep 89 21:28:21 GMT References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU> <1989Aug17.005548.745@twwells.com> <16022@vail.ICO.ISC.COM> <248@seti.inria.fr> <246@ssp1.idca.tds.philips.nl> <21952@cup.portal.com> <10983@smoke.BRL.MIL> <591@augean.OZ> <125@bbxsda.UUCP> <1 <137@bbxsda Reply-To: gwyn@brl.arpa (Doug Gwyn) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 34 In article <871@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >So how portable is a C program that examines a freed pointer without >dereferencing it? Probably not 100.000% portable, but close enough >that it makes little difference. People who have implementations like that wouldn't agree with you. >Then, if >you have any time left, you can relax over lunch and dwell on largely >theoretical endeavors...such as wondering if examining a freed pointer >will give you a C program that might not run on *every* possible >computer system that might exist in the entire world for the next >century. This is NOT an ivory-tower issue. I certainly wouldn't be wasting effort trying to explain it to you guys if it were. I personally believe that architectures for which this is a real issue SHOULD be designed, not just for dead-pointer access trapping, but in order to obtain other benefits of tagged architectures. The more code there is that will fail miserably on a reasonable tagged architecture, the more excuse there is for computer companies to not produce such architectures. Not too long ago I had a design engineer at one such company inform me that the opportunity to produce a bit-addressable architecture (which would be immensely helpful for many applications) was being lost due to the Catch-22 argument that existing code would not be able to use the bit-addressability feature. Thus, arguing that computer should continue to look just like the crufty pieces of junk you're currently used to can be to the long-term detriment of the computing industry. There is room for numerous architectural improvements, and to the extent that they can be anticipated and accommodated in programming language specifications, the better off we all will be.