From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 24 12:14:46 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 D387416A4CE for ; Sat, 24 Apr 2004 12:14:46 -0700 (PDT) Received: from mail.eecs.harvard.edu (bowser.eecs.harvard.edu [140.247.60.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FFCB43D5A for ; Sat, 24 Apr 2004 12:14:46 -0700 (PDT) (envelope-from ellard@eecs.harvard.edu) Received: by mail.eecs.harvard.edu (Postfix, from userid 465) id 168FB54C74C; Sat, 24 Apr 2004 15:14:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.eecs.harvard.edu (Postfix) with ESMTP id 140EB54C712; Sat, 24 Apr 2004 15:14:46 -0400 (EDT) Date: Sat, 24 Apr 2004 15:14:46 -0400 (EDT) From: Daniel Ellard To: Anton Alin-Adrian Message-ID: <20040424150618.S35754@bowser.eecs.harvard.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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:14:46 -0000 > 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