Martin Dorey wrote:
However, your point about programs invoked by make inheriting the
setrlimit() is definitely something that seems problematic. Perhaps
GNU
make could change the stack limit back to what it was after it forks
but
before it execs its child. I wonder what hap
> However, your point about programs invoked by make inheriting the
> setrlimit() is definitely something that seems problematic. Perhaps
GNU
> make could change the stack limit back to what it was after it forks
but
> before it execs its child. I wonder what happens if you change a
limit to
On Wed, 2006-11-29 at 13:22 +, Jon Grant wrote:
> > Finally, there is no way to detect an out of stack error and exit gracefully
> > with a warning as you suggest: the behavior of alloca() is undefined if you
> > run out of stack space (it doesn't just return NULL as malloc() etc. do).
> Is i
On Wed, 2006-11-29 at 05:49 -0800, Howard Chu wrote:
> Some modern mallocs are good, but stack-based allocation is still better
> a lot of the time. Especially for temporary variables that are just
> going to be discarded after a few computations.
Right. And remember it's not just the code man
Jon Grant wrote:
My view would be that on modern computers switching to allocate from the
heap wouldn't make a big difference if it were changed. Modern heaps
have pools for small allocations to stop them fragmenting larger
allocations anyway. Someone would need to do a compressive test to know
f
Hi,
Paul D. Smith elucidated on 29/11/06 02:27:
[...]
> Finally, there is no way to detect an out of stack error and exit gracefully
> with a warning as you suggest: the behavior of alloca() is undefined if you
> run out of stack space (it doesn't just return NULL as malloc() etc. do).
Is it unde
On Tue, 2006-11-28 at 18:45 -0800, Martin Dorey wrote:
> > Using heap, which requires a system call to get more memory
>
> (It doesn't affect the main point of Paul's reply but just for academic
> interest) no it doesn't:
> Even in less contrived applications, brk isn't called anything like as
>
> Using heap, which requires a system call to get more memory
(It doesn't affect the main point of Paul's reply but just for academic
interest) no it doesn't:
[EMAIL PROTECTED]:~/playpen$ cat ten-thousand-mallocs.c
#include
int main() {
for (int ii = 0; ii != 10 * 1000; ++ ii) {
free(mal
