svn - but smaller?

[Stephen Montgomery-Smith]

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.