From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] trunk r117912: Minor improvements to new stack-allocated Lisp objects. Date: Mon, 22 Sep 2014 18:00:27 +0300 Message-ID: <83fvfjya2c.fsf@gnu.org> References: <541FB63B.4070403@cs.ucla.edu> <541FC4DB.3050307@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1411398091 19984 80.91.229.3 (22 Sep 2014 15:01:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 22 Sep 2014 15:01:31 +0000 (UTC) Cc: dmantipov@yandex.ru, emacs-devel@gnu.org, eggert@cs.ucla.edu To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 22 17:01:23 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 1XW575-0002sf-D8 for ged-emacs-devel@m.gmane.org; Mon, 22 Sep 2014 17:01:15 +0200 Original-Received: from localhost ([::1]:47074 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW574-0006ak-VD for ged-emacs-devel@m.gmane.org; Mon, 22 Sep 2014 11:01:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53919) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW56e-0006ST-3E for emacs-devel@gnu.org; Mon, 22 Sep 2014 11:00:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XW56Z-00073j-Bx for emacs-devel@gnu.org; Mon, 22 Sep 2014 11:00:48 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:58190) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW56Y-00072I-Np for emacs-devel@gnu.org; Mon, 22 Sep 2014 11:00:43 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NCB00E005822400@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Mon, 22 Sep 2014 18:00:36 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NCB00DUP5OZXUA0@a-mtaout23.012.net.il>; Mon, 22 Sep 2014 18:00:36 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 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:174651 Archived-At: > From: Stefan Monnier > Date: Mon, 22 Sep 2014 08:57:13 -0400 > Cc: Paul Eggert , emacs-devel@gnu.org > > > SAFE_ALLOCA and friends has exactly the same problems, and I don't see > > the way to make it absolutely safe with an existing implementations of > > alloca. > > We don't need it to be absolutely safe (it's a given that using pointers > into stack-allocated objects is generally unsafe, unless we use some > code analysis to try and enforce some discipline). That's not the issue here, AFAIU. The issue here is that if you use SAFE_ALLOCA inside a loop, each call to it might decide to call alloca, because the size is small enough, but the sum of all allocations could easily exceed the stack space, certainly the 16KB limit we want to impose on such allocations. We don't have a lot of these in the sources, but we do have a few. > But the rules that have to be followed need to be *very* clear and > stated in the most obvious (or in your face) place. Where?