Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!apple!oliveb!tymix!cirrusl!mv1!dhesi From: dhesi@mv1.UUCP (Rahul Dhesi) Newsgroups: comp.lang.c Subject: Re: effect of free() Message-ID: <871@cirrusl.UUCP> Date: 22 Sep 89 02:53:50 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 Sender: news@cirrusl.UUCP Reply-To: dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) Organization: Cirrus Logic Inc. Lines: 44 In article <137@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes: >It >was pointed out that there are no new portability issues that haven't >been there all along. In other words, this pointer thing is not new. >However, nobody has been able to come up with an example where this >was actually a problem (unless I missed something). Maybe it is >because of the way people write their programs. Maybe it is because >C implementers didn't have a standard to hide behind and kept a wide >safety margin in their products. It's probably because portability is not a boolean attribute, and some things -- like examining a pointer after it has been given to free() -- correspond closely enough to the way most computer systems work that they are as near being perfectly portable as makes little difference. The purist point of view seems to be that portability an absolute attribute, and a C construct either "is" or "isn't" portable. The result is the typical "is!" "isn't!" portability war that you often see here. In actual practice, the question one really ought to ask is not "is it portable?" but "how portable is it?" 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. Before worrying about architectures that might not like the type of thing being discussed, worry about defining too many long macros, or having long literal strings, or having long external names, or using #if rather than #ifdef, or doing any type of token-pasting (whether or not ANSI-conformant), or using data structures that are bigger than 64 kilobytes, or using a word inside a literal string after defining a macro called by the same name, or continuing a macro definition to the next line, or any of hundreds of apparently-innocent things that make C programs less than perfectly portable in the real world. 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. -- Rahul Dhesi UUCP: oliveb!cirrusl!dhesi