From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 24 12:26:08 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 527AE16A4CE for ; Sat, 24 Apr 2004 12:26:08 -0700 (PDT) Received: from mail.1plan.net (ns1.1plan.net [216.240.143.74]) by mx1.FreeBSD.org (Postfix) with SMTP id 3589943D5A for ; Sat, 24 Apr 2004 12:26:08 -0700 (PDT) (envelope-from aanton@reversedhell.net) Received: (qmail 44218 invoked by uid 98); 24 Apr 2004 19:32:08 -0000 Received: from aanton@reversedhell.net by cp by uid 101 with qmail-scanner-1.20 (clamscan: 0.65. Clear:RC:1(81.196.32.25):SA:0(-100.0/5.0):. Processed in 1.415638 secs); 24 Apr 2004 19:32:08 -0000 X-Spam-Status: No, hits=-100.0 required=5.0 X-Qmail-Scanner-Mail-From: aanton@reversedhell.net via cp X-Qmail-Scanner: 1.20 (Clear:RC:1(81.196.32.25):SA:0(-100.0/5.0):. Processed in 1.415638 secs) Received: from unknown (HELO reversedhell.net) (81.196.32.25) by ns1.1plan.net with SMTP; 24 Apr 2004 19:32:07 -0000 Message-ID: <408ABF4E.5020106@reversedhell.net> Date: Sat, 24 Apr 2004 22:26:06 +0300 From: Anton Alin-Adrian User-Agent: Mozilla Thunderbird 0.5 (X11/20040303) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Ellard References: <20040424150618.S35754@bowser.eecs.harvard.edu> In-Reply-To: <20040424150618.S35754@bowser.eecs.harvard.edu> X-Enigmail-Version: 0.83.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD's malloc problem ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2004 19:26:08 -0000 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