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 loading progress Date: Thu, 19 Nov 2015 15:50:29 -0800 Organization: UCLA Computer Science Department Message-ID: <564E6045.6030907@cs.ucla.edu> References: <8737wgw7kf.fsf@lifelogs.com> <87io5bv1it.fsf@lifelogs.com> <87egfzuwca.fsf@lifelogs.com> <876118u6f2.fsf@lifelogs.com> <8737w3qero.fsf@lifelogs.com> <831tbn9g9j.fsf@gnu.org> <878u5upw7o.fsf@lifelogs.com> <83ziya8xph.fsf@gnu.org> <83y4du80xo.fsf@gnu.org> <564DF0F6.5060501@cs.ucla.edu> <564E5375.3050006@cs.ucla.edu> 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 1447977064 14078 80.91.229.3 (19 Nov 2015 23:51:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Nov 2015 23:51:04 +0000 (UTC) Cc: emacs-devel@gnu.org To: Philipp Stephani , Eli Zaretskii , Ted Zlatanov , =?UTF-8?Q?Aur=c3=a9lien_Aptel?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 20 00:50:56 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 1ZzYyd-0006aF-Ol for ged-emacs-devel@m.gmane.org; Fri, 20 Nov 2015 00:50:55 +0100 Original-Received: from localhost ([::1]:44560 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzYyd-0005Dr-AC for ged-emacs-devel@m.gmane.org; Thu, 19 Nov 2015 18:50:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40930) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzYyK-0005Co-KV for emacs-devel@gnu.org; Thu, 19 Nov 2015 18:50:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZzYyJ-0003Mw-Pa for emacs-devel@gnu.org; Thu, 19 Nov 2015 18:50:36 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:41129) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzYyF-0003La-KP; Thu, 19 Nov 2015 18:50:31 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 1ADF7160DFD; Thu, 19 Nov 2015 15:50:30 -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 NxKOUWN9BgsP; Thu, 19 Nov 2015 15:50:29 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6D35E160DFE; Thu, 19 Nov 2015 15:50:29 -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 TyK71MoR_ElF; Thu, 19 Nov 2015 15:50:29 -0800 (PST) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 500E6160DFD; Thu, 19 Nov 2015 15:50:29 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 In-Reply-To: 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:194832 Archived-At: On 11/19/2015 03:08 PM, Philipp Stephani wrote: > Returning NULL is fine. malloc also returns NULL on OOM, and module.c > handles that. I'm not so much worried about emacs-module.c. I'm worried about what modules will do. If we tell programmers 'just call xmalloc' things will be easy for them. If not, they'll be more likely to make mistakes. Is there some way xmalloc (actually, memory_full) can detect that it was invoked from a module rather than from ordinary Emacs code? If so, we could have memory_full do something different than call xsignal, in that case.