Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!zaphod.mps.ohio-state.edu!wuarchive!texbell!merch!sneaky!gordon From: gordon@sneaky.UUCP (Gordon Burditt) Newsgroups: comp.lang.c Subject: Re: FREE Message-ID: <29079@sneaky.UUCP> Date: 9 Mar 90 05:44:42 GMT References: <2714@stl.stc.co.uk> <1990Feb27.155133.20341@druid.uucp> <16055@haddock.ima.isc.com> <1990Mar1.140829.17199@druid.uucp> <1990Mar2.152601.8000@cubmol.bio.columbia.edu> <544@nlsun1.oracle.nl> Organization: Gordon Burditt Lines: 31 >| Why is NOT malloc() made to initialize the contents automatically? >Why would you spend time on this, if you have to put data into the area anyway? >I believe this is by far the most common use. I have on occasion put my own wrapper around malloc() to initialize the allocated memory area. The data to use for initialization was chosen so that (some of these objectives are processor-dependent): - If it's used as a pointer, you get a segmentation violation. - If it's used as a function pointer, it should be odd so you trap immediately. - If it's used as a floating point number, you get a number with an obnoxiously large exponent that's likely to overflow in calculations. - If it's used as an integer, it's very large and negative. - If it's printed in hex, it's recognizable. One number I used for this was the 4-byte constant: 0xdeadbee1. On another occasion I used the negative of the time(). I would like to add one criteria I couldn't satisfy: - If it's printed as a string, it's an obscenity. Also, it's very important that no portion of the program EXCEPT the wrapper around malloc() know what the constant is or any of its attributes. Using this technique with a program that made extensive use of linked lists helped to quickly trap failure to initialize back link pointers close to the point of the problem. After the program is working (you think), you can take out the debugging initialization part to speed up the program. Gordon L. Burditt sneaky.lonestar.org!gordon