From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Enlarge MAX_ALLOCA? Date: Thu, 19 Jun 2014 18:23:26 +0200 Organization: Organization?!? Message-ID: <87bnto98ch.fsf@fencepost.gnu.org> References: <83sin0sx98.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1403195048 5806 80.91.229.3 (19 Jun 2014 16:24:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Jun 2014 16:24:08 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 19 18:24:01 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Wxf83-00022D-Fz for ged-emacs-devel@m.gmane.org; Thu, 19 Jun 2014 18:23:59 +0200 Original-Received: from localhost ([::1]:36676 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wxf83-000217-2c for ged-emacs-devel@m.gmane.org; Thu, 19 Jun 2014 12:23:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57443) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wxf7u-000204-9o for emacs-devel@gnu.org; Thu, 19 Jun 2014 12:23:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wxf7n-00046s-K3 for emacs-devel@gnu.org; Thu, 19 Jun 2014 12:23:50 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:58844) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wxf7n-000414-DL for emacs-devel@gnu.org; Thu, 19 Jun 2014 12:23:43 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Wxf7k-0001e6-A9 for emacs-devel@gnu.org; Thu, 19 Jun 2014 18:23:40 +0200 Original-Received: from x2f49425.dyn.telefonica.de ([2.244.148.37]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 19 Jun 2014 18:23:40 +0200 Original-Received: from dak by x2f49425.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 19 Jun 2014 18:23:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 31 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: x2f49425.dyn.telefonica.de X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) Cancel-Lock: sha1:1X2/UJwTfwh28nUAoQgzPZ5m0a4= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:172535 Archived-At: Eli Zaretskii writes: > -#define SAFE_ALLOCA(size) ((size) < MAX_ALLOCA \ > +#define SAFE_ALLOCA(size) ((size) <= MAX_ALLOCA \ > ? alloca (size) \ > : (sa_must_free = true, record_xmalloc (size))) > > @@ -4469,7 +4469,7 @@ extern void *record_xmalloc (size_t) ATT > > #define SAFE_ALLOCA_LISP(buf, nelt) \ > do { \ > - if ((nelt) < MAX_ALLOCA / word_size) \ > + if ((nelt) <= MAX_ALLOCA / word_size) \ > (buf) = alloca ((nelt) * word_size); \ > else if ((nelt) < min (PTRDIFF_MAX, SIZE_MAX) / word_size) \ > { \ Bad idea to change < to <= here. If there is a hard limit due to short offsets or similar (and if there weren't, why bother at all?), then allocating a full 64kB might be a bad idea. With regard to short addressing modes, 32kB might be more appropriate, and if the normal stack frame is included in that address range, 30kB might be more cautious. 64kB feels arbitrary. I cannot really think of an architecture where 64kB would be feasible and 128kB not. ±32kB is a plausible offset for some architectures. -- David Kastrup