From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc. Date: Mon, 21 Dec 2015 22:44:55 -0800 Organization: UCLA Computer Science Department Message-ID: <5678F167.2040607@cs.ucla.edu> References: <83mvu1x6t3.fsf@gnu.org> <565779CD.80405@cs.ucla.edu> <83io4nuc68.fsf@gnu.org> <83r3iht93x.fsf@gnu.org> <838u4psznr.fsf@gnu.org> <56772054.8010401@cs.ucla.edu> <83zix4scgf.fsf@gnu.org> <5677DBC9.6030307@cs.ucla.edu> <83io3rst2r.fsf@gnu.org> <567841A6.4090408@cs.ucla.edu> <567844B9.2050308@dancol.org> <5678CD07.8080209@cs.ucla.edu> <5678D3AF.7030101@dancol.org> <5678D620.6070000@cs.ucla.edu> <5678D710.9010406@dancol.org> <5678E8FE.1010502@cs.ucla.edu> <5678EA4E.6080606@dancol.org> <5678EEA3.2060402@cs.ucla.edu> <5678EF14.6010707@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1450766729 23919 80.91.229.3 (22 Dec 2015 06:45:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Dec 2015 06:45:29 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, p.stephani2@gmail.com, tzz@lifelogs.com, emacs-devel@gnu.org To: Daniel Colascione , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 22 07:45:20 2015 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 1aBGhA-0005AV-T7 for ged-emacs-devel@m.gmane.org; Tue, 22 Dec 2015 07:45:17 +0100 Original-Received: from localhost ([::1]:48991 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBGhA-0007JZ-1o for ged-emacs-devel@m.gmane.org; Tue, 22 Dec 2015 01:45:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44988) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBGgy-0007JK-0P for emacs-devel@gnu.org; Tue, 22 Dec 2015 01:45:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBGgx-0003jh-71 for emacs-devel@gnu.org; Tue, 22 Dec 2015 01:45:03 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:39336) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBGgr-0003if-5Q; Tue, 22 Dec 2015 01:44:57 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 44EA816066A; Mon, 21 Dec 2015 22:44:56 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id X47e3j2qAheq; Mon, 21 Dec 2015 22:44:55 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8D1E3160D02; Mon, 21 Dec 2015 22:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AUWaf526L0ZX; Mon, 21 Dec 2015 22:44:55 -0800 (PST) Original-Received: from [192.168.1.9] (pool-100-32-155-148.lsanca.fios.verizon.net [100.32.155.148]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 5817316066A; Mon, 21 Dec 2015 22:44:55 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <5678EF14.6010707@dancol.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 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:196656 Archived-At: Daniel Colascione wrote: > It's programmable in Lisp. Lisp stack overflows shouldn't kill Emacs. > I'm suggesting that we shouldn't care about *C* stack overflows. The Lisp stack *is* the C stack. There is just one stack, which can overflow in module code or in Elisp interpreter code (or in library code or whatever). Whatever technique is used to detect Lisp stack overflows, should be usable to detect stack overflows in module calls.