Date: Sat, 24 Apr 2004 22:26:06 +0300 From: Anton Alin-Adrian <aanton@reversedhell.net> To: Daniel Ellard <ellard@eecs.harvard.edu> Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD's malloc problem ? Message-ID: <408ABF4E.5020106@reversedhell.net> In-Reply-To: <20040424150618.S35754@bowser.eecs.harvard.edu> References: <20040424150618.S35754@bowser.eecs.harvard.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Ellard wrote: > >>And let there be light... DANG.. well it almost blinded me. I was >>confusing with char[16], which has the +1 byte for the null >>terminating, but the malloc(16) hasn't... > > > No, that's still not quite it... > > char[16] allocates exactly 16 characters. Period. There's no extra > space on the end for the terminating nul. If you try to put a sixteen > character string into this array, the terminating nul will slop over > onto whatever follows this array in memory. > > malloc(16) is essentially the same. The difference is that there > might not be something right there to be clobbered. malloc tends to > round up the number of bytes to something convenient. It's easier to > manage a pool of things that are all the same size than a zillion > different sizes. 16 is pretty small -- the linux malloc might round > everything smaller than 20 bytes or 24 bytes (why 20 or 24? That's > another story...) to 20 or 24 bytes bytes just to make its life > easier. Therefore it's giving you four "extra" bytes and the nul can > clobber them without causing you to notice the bug. > > -Dan > Yes. Thanks ;). -- Alin-Adrian Anton Reversed Hell Networks GPG keyID 0x1E2FFF2E (2963 0C11 1AF1 96F6 0030 6EE9 D323 639D 1E2F FF2E) gpg --keyserver pgp.mit.edu --recv-keys 1E2FFF2E
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?408ABF4E.5020106>