GNU bug report logs - #18410
Use SAFE_ALLOCA etc. to avoid unbounded stack allocation.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18410 in the body.
You can then email your comments to 18410 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Emacs bug reports and feature requests <bug-gnu-emacs <at> gnu.org>
Subject: Use SAFE_ALLOCA etc. to avoid unbounded stack allocation.
Date: Thu, 04 Sep 2014 23:08:43 -0700

[Message part 1 (text/plain, inline)]

Tags: patch

Attached is a patch to fix the unbounded alloca calls that I found when 
auditing the Emacs source.  I'm sending this to bug-gnu-emacs to give 
Eli a heads-up, as some of the fixes affect Windows code.  This patch is 
relative to Emacs trunk bzr 117822.

[alloca.patch (text/plain, attachment)]

Message #8 received at 18410 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 18410 <at> debbugs.gnu.org
Subject: Re: bug#18410: Use SAFE_ALLOCA etc. to avoid unbounded stack
 allocation.
Date: Fri, 05 Sep 2014 12:45:27 +0400

On 09/05/2014 10:08 AM, Paul Eggert wrote:

> Attached is a patch to fix the unbounded alloca calls that I found when auditing the Emacs source.
> I'm sending this to bug-gnu-emacs to give Eli a heads-up, as some of the fixes affect Windows code.
> This patch is relative to Emacs trunk bzr 117822.

Code like:

USE_SAFE_ALLOCA;                                                    |-
ptrdiff_t count = SPECPDL_INDEX ();                    |-           |
...                                                    | inner bind | outer bind
Lisp_Object result = unbind_to (count, Fsome_func ()); |-           |
SAFE_FREE ();                                                       |-
return result;

looks suboptimal because it calls unbind_to twice.  May be we need SAFE_FREE_RETURN,
somewhat similar to RETURN_UNGCPRO?  I.e. we should be able to say:

USE_SAFE_ALLOCA;
ptrdiff_t count = SPECPDL_INDEX ();
...
SAFE_FREE_RETURN (Fsome_func ());

Minor note: why specbind can't return previous binding level?
To avoid extra typing, someone can write:

ptrdiff_t count = specbind (Qsome_var, Qnil);

instead of:

ptrdiff_t count = SPECPDL_INDEX ();
specbind (Qsome_var, Qnil);

Dmitry

Message #11 received at 18410 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 18410 <at> debbugs.gnu.org
Subject: Re: bug#18410: Use SAFE_ALLOCA etc. to avoid unbounded stack
 allocation.
Date: Fri, 05 Sep 2014 12:59:27 +0400

On 09/05/2014 10:08 AM, Paul Eggert wrote:

> Attached is a patch to fix the unbounded alloca calls that I found when auditing the Emacs source.
> I'm sending this to bug-gnu-emacs to give Eli a heads-up, as some of the fixes affect Windows code.
> This patch is relative to Emacs trunk bzr 117822.

If __GNUC__, can't we use __attribute__ ((cleanup (freeing_function))) for implicit calls
to SAFE_FREE, similar to destructors in C++?

Dmitry

Message #14 received at 18410 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: 18410 <at> debbugs.gnu.org
Subject: Re: bug#18410: Use SAFE_ALLOCA etc. to avoid unbounded stack
 allocation.
Date: Fri, 05 Sep 2014 08:01:31 -0700

Dmitry Antipov wrote:
> USE_SAFE_ALLOCA;                                                    |-
> ptrdiff_t count = SPECPDL_INDEX ();                    |-           |
> ...                                                    | inner bind |
> outer bind
> Lisp_Object result = unbind_to (count, Fsome_func ()); |-           |
> SAFE_FREE ();                                                       |-
> return result;
>
> looks suboptimal because it calls unbind_to twice.

I noticed that too, and actually coded up something along those lines, 
but decided to discard it as it added complexity and the patch was 
already pretty large.  There is some virtue in having a simpler API, 
even if it's a tad suboptimal.  Perhaps we can think of a way of 
combining SAFE_FREE and unbind_to so that there aren't two different 
ways in the source code of doing the same thing.

To be honest I've never been a fan of 'RETURN_UNGCPRO (expr);', and 
would rather not encourage other macros along those lines.  I was hoping 
that we could get rid of all the GCPRO stuff, and simplify the code 
under the assumption that GC_MARK_STACK == GC_MAKE_GCPROS_NOOPS.

I do like the idea about specbind returning the previous SPECPDL_INDEX, 
as that would simplify the code.

Message #17 received at 18410 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: 18410 <at> debbugs.gnu.org
Subject: Re: bug#18410: Use SAFE_ALLOCA etc. to avoid unbounded stack
 allocation.
Date: Fri, 05 Sep 2014 08:03:54 -0700

Dmitry Antipov wrote:
> If __GNUC__, can't we use __attribute__ ((cleanup (freeing_function)))
> for implicit calls
> to SAFE_FREE

We could, but I don't see how this would help.  For non-GNUC we need to 
call the freeing function explicitly anyway, so __attribute__ ((cleanup 
...)) would simply clutter up the source, no?  Or perhaps I'm not 
understanding the suggestion.

Message #20 received at 18410 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 18410 <at> debbugs.gnu.org
Subject: Re: bug#18410: Use SAFE_ALLOCA etc. to avoid unbounded stack
 allocation.
Date: Fri, 05 Sep 2014 11:44:25 -0400

> USE_SAFE_ALLOCA;                                                    |-
> ptrdiff_t count = SPECPDL_INDEX ();                    |-           |
> ...                                                    | inner bind | outer bind
> Lisp_Object result = unbind_to (count, Fsome_func ()); |-           |
> SAFE_FREE ();                                                       |-
> return result;
>
> looks suboptimal because it calls unbind_to twice.

Only if the object is "too large" and requires heap allocation.

BTW, AFAIK

   Lisp_Object result = unbind_to (count, Fsome_func ());

can always be written

   Lisp_Object result = Fsome_func ();
   unbind_to (count, Qnil);

which I find more readable (if it were me, unbind_to would take
a single arg and return void).


        Stefan

Message #23 received at 18410 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Dmitry Antipov <dmantipov <at> yandex.ru>, 18410 <at> debbugs.gnu.org,
 Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#18410: Use SAFE_ALLOCA etc. to avoid unbounded stack
 allocation.
Date: Fri, 05 Sep 2014 18:04:53 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> BTW, AFAIK
>
>    Lisp_Object result = unbind_to (count, Fsome_func ());
>
> can always be written
>
>    Lisp_Object result = Fsome_func ();
>    unbind_to (count, Qnil);

Only if the result is already protected, since unbind_to can GC.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #26 received at 18410 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: Dmitry Antipov <dmantipov <at> yandex.ru>, 18410 <at> debbugs.gnu.org,
 Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#18410: Use SAFE_ALLOCA etc. to avoid unbounded stack
 allocation.
Date: Fri, 05 Sep 2014 13:22:21 -0400

>> Lisp_Object result = unbind_to (count, Fsome_func ());
>> can always be written
>> Lisp_Object result = Fsome_func ();
>> unbind_to (count, Qnil);
> Only if the result is already protected, since unbind_to can GC.

Indeed, if you need GCPRO, then it's not necessarily true any more.


        Stefan

Message #31 received at 18410-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 18410-done <at> debbugs.gnu.org
Subject: Re: Use SAFE_ALLOCA etc. to avoid unbounded stack allocation.
Date: Sun, 07 Sep 2014 00:20:33 -0700

I installed the patch as trunk bzr 117829 and am marking this as done.

Message #34 received at 18410 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 18410 <at> debbugs.gnu.org
Subject: Re: bug#18410: Use SAFE_ALLOCA etc. to avoid unbounded stack
 allocation.
Date: Sun, 07 Sep 2014 20:09:25 +0300

> Date: Sun, 07 Sep 2014 00:20:33 -0700
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> I installed the patch as trunk bzr 117829 and am marking this as done.

What is the rationale for tests such as this one in callproc.c:

    if (MAX_ALLOCA / sizeof *env - 2 < new_length)
      exec_failed (new_argv[0], ENOMEM);

MAX_ALLOCA is a relatively small number compared to the stack space
available on modern systems, so I see no reason to fail and exit in
these cases, it sounds too drastic.

Perhaps we should have a separate constant with platform-specific
value, if we want such tests.  Or maybe make them conditional on
ENABLE_CHECKING.

Message #37 received at 18410 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 18410 <at> debbugs.gnu.org
Subject: Re: bug#18410: Use SAFE_ALLOCA etc. to avoid unbounded stack
 allocation.
Date: Sun, 07 Sep 2014 13:33:10 -0700

Eli Zaretskii wrote:
> MAX_ALLOCA is a relatively small number compared to the stack space
> available on modern systems, so I see no reason to fail and exit in
> these cases, it sounds too drastic.

Usually MAX_ALLOCA-related code falls back on malloc, and does not exit 
merely because a request was larger.  callproc.c's child_setup function 
is special, though, as it executes in a vforked child that cannot safely 
call malloc because that would screw up the parent's malloc arena.  In 
this special case the child exits (Emacs itself doesn't), so it's not 
that drastic.  It'd be nicer if Emacs would allocate the memory before 
vforking the child, as that would avoid the limitation, but I daresay 
it's not urgent to fix this.  It should be commented better, though, and 
I gave that a shot in trunk bzr 117837.

Quite possibly we should increase MAX_ALLOCA on many modern systems.  As 
I recall we last discussed that in July, and Stefan was worried about 
max-lisp-eval-depth * MAX_ALLOCA * N overflowing the C stack, where N is 
the maximum nesting depth of SAFE_ALLOCA-using C functions between Lisp 
functions.  Perhaps some of that discussion is moot now, with the stack 
overflow checking that Dmitry added last month?

Message #40 received at 18410 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 18410 <at> debbugs.gnu.org
Subject: Re: bug#18410: Use SAFE_ALLOCA etc. to avoid unbounded stack
 allocation.
Date: Sun, 07 Sep 2014 22:22:23 -0400

> Usually MAX_ALLOCA-related code falls back on malloc, and does not exit
> merely because a request was larger.  callproc.c's child_setup function is

MAX_ALLOCA is chosen small so that we can allocate several/many objects
of size MAX_ALLOCA.  Whereas in this case, after this alloca we're not
expected to use up the stack much more (we're about to `exec' anyway,
right?).  So MAX_ALLOCA is much too conservative for this case.


        Stefan

Message #43 received at 18410 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: eggert <at> cs.ucla.edu, 18410 <at> debbugs.gnu.org
Subject: Re: bug#18410: Use SAFE_ALLOCA etc. to avoid unbounded stack
 allocation.
Date: Mon, 08 Sep 2014 05:35:28 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  18410 <at> debbugs.gnu.org
> Date: Sun, 07 Sep 2014 22:22:23 -0400
> 
> > Usually MAX_ALLOCA-related code falls back on malloc, and does not exit
> > merely because a request was larger.  callproc.c's child_setup function is
> 
> MAX_ALLOCA is chosen small so that we can allocate several/many objects
> of size MAX_ALLOCA.  Whereas in this case, after this alloca we're not
> expected to use up the stack much more (we're about to `exec' anyway,
> right?).  So MAX_ALLOCA is much too conservative for this case.

Indeed, I agree.  So I think we should increase the limit in
callproc.c, especially if we are going to keep the exit with failed
status when the limit is exceeded.

Message #46 received at 18410 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 18410 <at> debbugs.gnu.org
Subject: Re: bug#18410: Use SAFE_ALLOCA etc. to avoid unbounded stack
 allocation.
Date: Mon, 08 Sep 2014 05:36:24 +0300

> Date: Sun, 07 Sep 2014 13:33:10 -0700
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: 18410 <at> debbugs.gnu.org
> 
> Perhaps some of that discussion is moot now, with the stack overflow
> checking that Dmitry added last month?

I'd say it's definitely moot on systems where that stack-overflow code
is working.

Message #49 received at 18410 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 18410 <at> debbugs.gnu.org
Subject: Re: bug#18410: Use SAFE_ALLOCA etc. to avoid unbounded stack
 allocation.
Date: Sun, 07 Sep 2014 19:38:17 -0700

Stefan Monnier wrote:
> MAX_ALLOCA is chosen small so that we can allocate several/many objects
> of size MAX_ALLOCA.

That's one reason, but another is that stack-overflow checking often 
relies on guard pages.  If we blindly increase MAX_ALLOCA (or some 
variant of it, just for call-process) Emacs could bypass stack-overflow 
checking, resulting in behavior that could be worse than simply dumping 
core.

If I understand things correctly, Dmitry's recent stack-overflow changes 
don't affect this, as they don't deal with the guard-page region size.

Message #52 received at 18410 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 18410 <at> debbugs.gnu.org
Subject: Re: bug#18410: Use SAFE_ALLOCA etc. to avoid unbounded stack
 allocation.
Date: Sun, 07 Sep 2014 22:43:50 -0400

> Indeed, I agree.  So I think we should increase the limit in
> callproc.c, especially if we are going to keep the exit with failed
> status when the limit is exceeded.

I don't even see any need for checking at all.


        Stefan

Message #55 received at 18410 <at> debbugs.gnu.org (full text, mbox):

From: "Demetrios Obenour" <demetriobenour <at> gmail.com>
To: "'Paul Eggert'" <eggert <at> cs.ucla.edu>,
 "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 18410 <at> debbugs.gnu.org
Subject: RE: bug#18410: Use SAFE_ALLOCA etc. to avoid unbounded stack
 allocation.
Date: Sun, 7 Sep 2014 23:17:30 -0400

This is crucial. Otherwise, a security vulnerability could result.

MAX_ALLOCA should not be larger than the page size for the target architecture.

Demetrios Obenour

-----Original Message-----
From: bug-gnu-emacs-bounces+demetriobenour=gmail.com <at> gnu.org [mailto:bug-gnu-emacs-bounces+demetriobenour=gmail.com <at> gnu.org] On Behalf Of Paul Eggert
Sent: Sunday, September 7, 2014 10:38 PM
To: Stefan Monnier
Cc: 18410 <at> debbugs.gnu.org
Subject: bug#18410: Use SAFE_ALLOCA etc. to avoid unbounded stack allocation.

Stefan Monnier wrote:
> MAX_ALLOCA is chosen small so that we can allocate several/many 
> objects of size MAX_ALLOCA.

That's one reason, but another is that stack-overflow checking often relies on guard pages.  If we blindly increase MAX_ALLOCA (or some variant of it, just for call-process) Emacs could bypass stack-overflow checking, resulting in behavior that could be worse than simply dumping core.

If I understand things correctly, Dmitry's recent stack-overflow changes don't affect this, as they don't deal with the guard-page region size.

Message #58 received at 18410 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: Demetrios Obenour <demetriobenour <at> gmail.com>, 
 'Paul Eggert' <eggert <at> cs.ucla.edu>,
 'Stefan Monnier' <monnier <at> iro.umontreal.ca>
Cc: 18410 <at> debbugs.gnu.org
Subject: Re: bug#18410: Use SAFE_ALLOCA etc. to avoid unbounded stack
 allocation.
Date: Sun, 07 Sep 2014 20:19:48 -0700

[Message part 1 (text/plain, inline)]

On 09/07/2014 08:17 PM, Demetrios Obenour wrote:
> This is crucial. Otherwise, a security vulnerability could result.
> 
> MAX_ALLOCA should not be larger than the page size for the target architecture.

You could just touch every page inside a large alloca.

[signature.asc (application/pgp-signature, attachment)]

Message #61 received at 18410 <at> debbugs.gnu.org (full text, mbox):

From: "Demetrios Obenour" <demetriobenour <at> gmail.com>
To: "'Daniel Colascione'" <dancol <at> dancol.org>,
 "'Paul Eggert'" <eggert <at> cs.ucla.edu>,
 "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 18410 <at> debbugs.gnu.org
Subject: RE: bug#18410: Use SAFE_ALLOCA etc. to avoid unbounded stack
 allocation.
Date: Sun, 7 Sep 2014 23:20:47 -0400

That would work also, and is probably the best approach.

-----Original Message-----
From: Daniel Colascione [mailto:dancol <at> dancol.org] 
Sent: Sunday, September 7, 2014 11:20 PM
To: Demetrios Obenour; 'Paul Eggert'; 'Stefan Monnier'
Cc: 18410 <at> debbugs.gnu.org
Subject: Re: bug#18410: Use SAFE_ALLOCA etc. to avoid unbounded stack allocation.

On 09/07/2014 08:17 PM, Demetrios Obenour wrote:
> This is crucial. Otherwise, a security vulnerability could result.
> 
> MAX_ALLOCA should not be larger than the page size for the target architecture.

You could just touch every page inside a large alloca.

Message #64 received at 18410 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Paul Eggert <eggert <at> cs.ucla.edu>, 
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 18410 <at> debbugs.gnu.org
Subject: Re: bug#18410: Use SAFE_ALLOCA etc. to avoid unbounded stack
 allocation.
Date: Mon, 08 Sep 2014 11:26:05 +0400

On 09/08/2014 06:38 AM, Paul Eggert wrote:

> If I understand things correctly, Dmitry's recent stack-overflow changes
> don't  affect this, as they don't deal with the guard-page region size.

Yes.  Guard-page approach has an unsolvable problem with dynamically adjusted
stack size (prlimit on GNU/Linux) - you just don't know where the guard page
should be, and there is no OS-level capability to notify an application about
stack size change.

Dmitry

Message #67 received at 18410 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 18410 <at> debbugs.gnu.org
Subject: Re: bug#18410: Use SAFE_ALLOCA etc. to avoid unbounded stack
 allocation.
Date: Mon, 08 Sep 2014 08:48:50 -0400

>> Perhaps some of that discussion is moot now, with the stack overflow
>> checking that Dmitry added last month?
> I'd say it's definitely moot on systems where that stack-overflow code
> is working.

I disagree.  Even if the new stack-overflow code works, it doesn't
change the fact that a stack-overflow is a problem for the end-user and
we should try to avoid causing such things.

IOW, Dmitry's overflow-handling is good because it makes the failure
a bit cleaner, but it's still a failure that we should strive to avoid.


        Stefan

Message #70 received at 18410 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: eggert <at> cs.ucla.edu, 18410 <at> debbugs.gnu.org
Subject: Re: bug#18410: Use SAFE_ALLOCA etc. to avoid unbounded stack
 allocation.
Date: Tue, 09 Sep 2014 16:17:41 +0300

> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 18410 <at> debbugs.gnu.org
> Date: Mon, 08 Sep 2014 08:48:50 -0400
> 
> >> Perhaps some of that discussion is moot now, with the stack overflow
> >> checking that Dmitry added last month?
> > I'd say it's definitely moot on systems where that stack-overflow code
> > is working.
> 
> I disagree.  Even if the new stack-overflow code works, it doesn't
> change the fact that a stack-overflow is a problem for the end-user and
> we should try to avoid causing such things.
> 
> IOW, Dmitry's overflow-handling is good because it makes the failure
> a bit cleaner, but it's still a failure that we should strive to avoid.

Actually, we are in violent agreement.  The point I was making is that
given that we want to check for stack overflow, we don't need 2 such
checks.  I didn't mean at all to say that we should be less careful
about avoiding stack overflows.

Message #73 received at 18410 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 18410 <at> debbugs.gnu.org
Subject: Re: bug#18410: Use SAFE_ALLOCA etc. to avoid unbounded stack
 allocation.
Date: Tue, 09 Sep 2014 09:49:32 -0400

> Actually, we are in violent agreement.  The point I was making is that
> given that we want to check for stack overflow, we don't need 2 such
> checks.  I didn't mean at all to say that we should be less careful
> about avoiding stack overflows.

Good.

I just wanted to clarify since the "moot discussion" was about
increasing MAX_ALLOCA, which would increase the risk of stack overflow.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.