Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!taumet!steve From: steve@taumet.com (Stephen Clamage) Newsgroups: comp.lang.c Subject: Re: Just a minor new twist on free() Message-ID: <472@taumet.com> Date: 11 Oct 90 15:31:38 GMT References: <8026@scolex.sco.COM> <11@christmas.UUCP> <1990Oct10.155448.1465@Neon.Stanford.EDU> Organization: Taumetric Corporation, San Diego Lines: 24 dkeisen@Gang-of-Four.Stanford.EDU (Dave Eisen) writes: >I'd prefer free not check for NULL pointers because I'd rather have >my sloppy (and probably incorrect) programming caught by a core dump >than slipping by untouched. I never check for NULL pointers in library >routines that I write unless there is a useful action that should be taken >when that pointer is NULL. The problem with this approach is that you can't depend on an immediate core dump just because the current pointer is incorrectly null. The core dump may occur at any arbitrary later time due to following garbage pointers -- or the program may not abort, but loop forever or do something bizarre. In particular, the problem may occur only after doing some irreversible bad thing -- like deleting all the files from your disk, or launching a missile with a nuclear warhead. It is inconvenient to have to rebuild your disk (or San Francisco) before trying to track down the program bug. IMHO, it is best to program defensively and catch errors as soon as possible. A library function should return an explicit or implicit error code -- or do nothing -- rather than try to use invalid data. -- Steve Clamage, TauMetric Corp, steve@taumet.com