Date: Mon, 6 Oct 2003 00:31:09 -0500 From: Dan Nelson <dnelson@allantgroup.com> To: James Jacobsen <james_jacobsen@lycos.co.uk> Cc: freebsd-questions@freebsd.org Subject: Re: malloc() behavior (was: Pointer please) Message-ID: <20031006053109.GM5283@dan.emsphone.com> In-Reply-To: <20031006052042.GA22536@res241015.resnet.wsu.edu> References: <27DDB356-F790-11D7-9174-003065838A88@mulle-kybernetik.com> <20031006030656.GK5283@dan.emsphone.com> <16256.57227.924291.290786@jerusalem.litteratus.org> <20031006033200.GL5283@dan.emsphone.com> <20031006042751.GA85685@res241015.resnet.wsu.edu> <16256.62127.618353.861297@jerusalem.litteratus.org> <20031006052042.GA22536@res241015.resnet.wsu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Oct 05), James Jacobsen said: > On 10/05/03 21:42:23, Robert Huff wrote: > >James Jacobsen writes: > >> It does not matter what freebsd does, C does not require that > >> malloc initialize space according to Kernighan and Ritchie. > > > >I knew that, and agree depending on a particular behavior is bad > >programming practice. That said, there's a lot of "bad programmers" > >out there .... > > What's really bad, is that freebsd could potentally change there > behavor down the line. Its probably dictated by the way kernel > dezined, meaning they may do whats the cheapist. I would. If they > do its go to lead to some weird behavior. :-) There's nothing bad about it. FreeBSD follows the standards. The debugging flags simply change what the undefined behaviour is. If you malloc a block of memory, you cannot rely on what data it currently contains. FreeBSD lets you zero it, fill it with a set value, or leave it. Programs exhibiting weird behaviour under any of those three cases are broken. Most debugging mallocs will trigger it, purify will probably catch it (never used it), and valgrind under Linux will definitely catch it. -- Dan Nelson dnelson@allantgroup.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031006053109.GM5283>