From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 22:14:43 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4AC1C1C4; Sun, 24 Feb 2013 22:14:43 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from wilberforce.math.missouri.edu (wilberforce.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id E710C88E; Sun, 24 Feb 2013 22:14:42 +0000 (UTC) Received: from [127.0.0.1] (wilberforce.math.missouri.edu [128.206.184.213]) by wilberforce.math.missouri.edu (8.14.6/8.14.6) with ESMTP id r1OMEWc6081849; Sun, 24 Feb 2013 16:14:33 -0600 (CST) (envelope-from stephen@missouri.edu) Message-ID: <512A90C8.6050007@missouri.edu> Date: Sun, 24 Feb 2013 16:14:32 -0600 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: svn - but smaller? References: <1359380582-6256705.77592125.fr0SDgrYH000991@rs149.luxsci.com> <20130224031509.GA47838@icarus.home.lan> <20130224041638.GA51493@icarus.home.lan> <20130224063110.GA53348@icarus.home.lan> <1361726397.16937.4.camel@revolution.hippie.lan> <20130224212436.GA13670@icarus.home.lan> In-Reply-To: <20130224212436.GA13670@icarus.home.lan> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Michael Ross , freebsd-stable@FreeBSD.org, John Mehr , Ian Lepore X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 22:14:43 -0000 On 02/24/2013 03:24 PM, Jeremy Chadwick wrote: > On Sun, Feb 24, 2013 at 10:19:57AM -0700, Ian Lepore wrote: >> On Sat, 2013-02-23 at 22:31 -0800, Jeremy Chadwick wrote: >>> >>> Also, John, please consider using malloc(3) instead of heap-allocated >>> buffers like file_buffer[6][] (196608 bytes) and command[] (32769 >>> bytes). I'm referring to this: >> >> Why? I absolutely do not understand why people are always objecting to >> large stack-allocated arrays in userland code (sometimes with the >> definition of "large" being as small as 2k for some folks). > > This is incredibly off-topic, but I'll bite. > > I should not have said "heap-allocated", I was actually referring to > statically-allocated. > > The issues as I see them: > > 2. If the length of the buffer exceeds the amount of stack space > available at the time, the program will run but the behaviour is unknown > (I know that on FreeBSD if it exceeds "stacksize" per resource limits, > the program segfaults at runtime). With malloc and friends you can > gracefully handle allocation failures. This actually happened to me. The program mkctm used to allocate space using alloca (which is the same as declaring it like char file_buffer[big_no] if big_no could be variable). But this is space on the stack as opposed to the heap, and if you type the command "limit" you will see that the stack size is typically much smaller than the heap size. And on 32 bit machines, the default value of stack size is rather small. Anyway, one day mkctm stopped working for me, and precisely for this reason. It took me a day to trace the fault, and I ended up rewriting the code to use malloc instead. (mkctm is a little known program, whose code is included in the FreeBSD base, to create updates for the CTM delivery method.) Probably on 64 bit machines it is not such a big issue. And on Linux, I think it makes no difference at all, because on Linux all data is stored on the heap.