On Mon, 2010-07-19 at 11:29 +0200, Edward Welbourne wrote:
Probably there should be an effort to switch to heap for anything that
might get large and reserve alloca() usage just for things we know for a
fact will not get too large, but that hasn't been done.
... and anywhere you use a
Probably there should be an effort to switch to heap for anything that
might get large and reserve alloca() usage just for things we know for a
fact will not get too large, but that hasn't been done.
... and anywhere you use a scanf variant, glibc is also using
alloca(), without knowing any
On Sat, 2010-07-17 at 02:22 -0300, Alberto Bertogli wrote:
Chasing a bug, I noticed that make sets RLIMIT_STACK to RLIM_INFINITY.
In Linux (since 2.6.25), that actually triggers a very subtle behaviour
change in the way the kernel manages the memory layout. While most
applications are
On Sun, 2010-07-18 at 14:40 -0300, Alberto Bertogli wrote:
The layout is decided by the kernel early, when the new process is being
created in execve(), and cannot be changed while running.
I did suspect as much: it seemed impossible (or at least highly
unlikely) for this to be changed during
On Sun, Jul 18, 2010 at 12:54:56PM -0400, Paul Smith wrote:
On Sat, 2010-07-17 at 02:22 -0300, Alberto Bertogli wrote:
Chasing a bug, I noticed that make sets RLIMIT_STACK to RLIM_INFINITY.
In Linux (since 2.6.25), that actually triggers a very subtle behaviour
change in the way the
On Sun, Jul 18, 2010 at 02:40:19PM -0300, Alberto Bertogli wrote:
Peeking around the source browser I notice that the change that introduced
the setrlimit() you describe is commit 1.191, dated 2008-11-30, which is
post-3.81.
Seeing that, I tried the latest alpha release (3.81.90), and it
On Sat, 2010-07-17 at 02:22 -0300, Alberto Bertogli wrote:
So I was wondering what was the reason for that rlimit, and if perhaps
it could be avoided to prevent this behaviour change.
It was added a number of years ago by Paul Eggert, because make makes
extensive use of alloca() and some
