From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Thu, 19 Nov 2015 23:55:57 +0000 Message-ID: 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> <564E6045.6030907@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114423389fe2470524ed8049 X-Trace: ger.gmane.org 1447977377 18720 80.91.229.3 (19 Nov 2015 23:56:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Nov 2015 23:56:17 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert , 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:56:16 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 1ZzZ3n-0007g6-Hu for ged-emacs-devel@m.gmane.org; Fri, 20 Nov 2015 00:56:15 +0100 Original-Received: from localhost ([::1]:44583 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzZ3m-0007hI-Jq for ged-emacs-devel@m.gmane.org; Thu, 19 Nov 2015 18:56:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42425) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzZ3i-0007hC-Ew for emacs-devel@gnu.org; Thu, 19 Nov 2015 18:56:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZzZ3h-0004xJ-K6 for emacs-devel@gnu.org; Thu, 19 Nov 2015 18:56:10 -0500 Original-Received: from mail-wm0-x22d.google.com ([2a00:1450:400c:c09::22d]:34711) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzZ3g-0004wu-16; Thu, 19 Nov 2015 18:56:08 -0500 Original-Received: by wmvv187 with SMTP id v187so49745473wmv.1; Thu, 19 Nov 2015 15:56:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=531tJQGFQJIRPjvV2fsvIR/qm9FVL0J172qhav5tV2M=; b=IYKljC4JnJ83ItFdfLnNi8wkhuVXxI61Eee7MvmDMwCQnoSFk4vLh7Oa85IMRIq16g 1YKRnAl9mVyqHe7hqT9xI/oslt5e9rETtNwW7uXYxgaagmq2LY+0j4pEvCCgncoWqdwY wMay4aZIsvQHFc29JhF1vTDX/DxX/xBWrU6k78JBxhXknbVzDW3E8dr3BrsWz5GYxjSL ny10Dj40ZZgoAEwrBu4zAwfotr4EWR9hLnoPqrCS/kjL+PiEo3qrN4YAjOuVNThYVPgG 4lZMw0T78T85iAnVhh0R5yJ7ckzUC6e6AFssr7CPFTZaKQ0OadEA+RTC0nnI0N7aTj19 z5Cw== X-Received: by 10.28.134.199 with SMTP id i190mr438487wmd.33.1447977367362; Thu, 19 Nov 2015 15:56:07 -0800 (PST) In-Reply-To: <564E6045.6030907@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::22d 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:194834 Archived-At: --001a114423389fe2470524ed8049 Content-Type: text/plain; charset=UTF-8 Paul Eggert schrieb am Fr., 20. Nov. 2015 um 00:50 Uhr: > 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. > Modules cannot (legally) call xmalloc. They need to obtain memory using malloc or any other standard function. In general, modules cannot call any functions except those declared in emacs-module.h. --001a114423389fe2470524ed8049 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Paul E= ggert <eggert@cs.ucla.edu> = schrieb am Fr., 20. Nov. 2015 um 00:50=C2=A0Uhr:
On 11/19/2015 03:08 PM, Philipp Stephani wrote:
> Returning NULL is fine. malloc also returns NULL on OOM, and module.c<= br> > handles that.

I'm not so much worried about emacs-module.c. I'm worried about wha= t
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.

Modules cannot (legally) call xma= lloc. They need to obtain memory using malloc or any other standard functio= n. In general, modules cannot call any functions except those declared in e= macs-module.h.
--001a114423389fe2470524ed8049--