From unknown Mon Jun 23 07:50:17 2025 X-Loop: help-debbugs@gnu.org Subject: bug#58739: Lack of error message about number of args (?native compilation?) Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 23 Oct 2022 12:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 58739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 58739@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.166652719021045 (code B ref -1); Sun, 23 Oct 2022 12:14:02 +0000 Received: (at submit) by debbugs.gnu.org; 23 Oct 2022 12:13:10 +0000 Received: from localhost ([127.0.0.1]:43803 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1omZqo-0005TN-Ef for submit@debbugs.gnu.org; Sun, 23 Oct 2022 08:13:10 -0400 Received: from lists.gnu.org ([209.51.188.17]:50268) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1omZql-0005TF-SR for submit@debbugs.gnu.org; Sun, 23 Oct 2022 08:13:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1omZql-0006Y9-7d for bug-gnu-emacs@gnu.org; Sun, 23 Oct 2022 08:13:07 -0400 Received: from mx3.muc.de ([193.149.48.5]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1omZqj-0007oY-2T for bug-gnu-emacs@gnu.org; Sun, 23 Oct 2022 08:13:06 -0400 Received: (qmail 58759 invoked by uid 3782); 23 Oct 2022 14:12:49 +0200 Received: from acm.muc.de (p2e5d5154.dip0.t-ipconnect.de [46.93.81.84]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 23 Oct 2022 14:12:49 +0200 Received: (qmail 24445 invoked by uid 1000); 23 Oct 2022 12:12:49 -0000 Date: Sun, 23 Oct 2022 12:12:49 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.5; envelope-from=acm@muc.de; helo=mx3.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) Hello, Emacs. Firstly, note that the function desktop-buffer has exactly 12 parameters. With an up to date Emacs 29: (i) emacs -Q (ii) M-x load-library RET desktop RET. (iii) M-x disassemble RET desktop-buffer. Note that this is native code. (iv) M-: (desktop-buffer 1 2 3 4 5 6 7 8 9 10 11 12 13) RET This gives an error message about 4 not being a list. What it ought to do is instead throw an error about the number of arguments. This is a bug. (v) M-x load-file RET /path/to/emacs/lisp/desktop.elc. (vi) M-x disassemble RET desktop-buffer. Note that we now have byte compiled code. (vii) M-: (desktop-buffer 1 2 3 4 5 6 7 8 9 10 11 12 13) RET We now get a correct error message about the numbere of arguments. As a matter of interest, I noticed this bug while byte-compiling desktop.el inside Emacs. It gave a warning message about the number of parameters to desktop-buffer having changed from 12+ to 12. Here, I suspect there's a bug in the native compilation of desktop-buffer. -- Alan Mackenzie (Nuremberg, Germany). From unknown Mon Jun 23 07:50:17 2025 X-Loop: help-debbugs@gnu.org Subject: bug#58739: Lack of error message about number of args (?native compilation?) Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 24 Oct 2022 16:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Andrea Corallo Cc: 58739@debbugs.gnu.org, acm@muc.de Received: via spool by 58739-submit@debbugs.gnu.org id=B58739.166662970313292 (code B ref 58739); Mon, 24 Oct 2022 16:42:02 +0000 Received: (at 58739) by debbugs.gnu.org; 24 Oct 2022 16:41:43 +0000 Received: from localhost ([127.0.0.1]:49354 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1on0WE-0003SK-Vs for submit@debbugs.gnu.org; Mon, 24 Oct 2022 12:41:43 -0400 Received: from mx3.muc.de ([193.149.48.5]:46527) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1on0WC-0003Rs-G0 for 58739@debbugs.gnu.org; Mon, 24 Oct 2022 12:41:42 -0400 Received: (qmail 59395 invoked by uid 3782); 24 Oct 2022 18:41:26 +0200 Received: from acm.muc.de (p4fe15cdd.dip0.t-ipconnect.de [79.225.92.221]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 24 Oct 2022 18:41:25 +0200 Received: (qmail 6569 invoked by uid 1000); 24 Oct 2022 16:41:25 -0000 Date: Mon, 24 Oct 2022 16:41:25 +0000 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Andrea. On Sun, Oct 23, 2022 at 12:12:49 +0000, Alan Mackenzie wrote: > Hello, Emacs. > Firstly, note that the function desktop-buffer has exactly 12 > parameters. > With an up to date Emacs 29: > (i) emacs -Q > (ii) M-x load-library RET desktop RET. > (iii) M-x disassemble RET desktop-buffer. > Note that this is native code. > (iv) M-: (desktop-buffer 1 2 3 4 5 6 7 8 9 10 11 12 13) RET > This gives an error message about 4 not being a list. What it ought to > do is instead throw an error about the number of arguments. This is a > bug. > (v) M-x load-file RET /path/to/emacs/lisp/desktop.elc. > (vi) M-x disassemble RET desktop-buffer. > Note that we now have byte compiled code. > (vii) M-: (desktop-buffer 1 2 3 4 5 6 7 8 9 10 11 12 13) RET > We now get a correct error message about the numbere of arguments. > As a matter of interest, I noticed this bug while byte-compiling > desktop.el inside Emacs. It gave a warning message about the number of > parameters to desktop-buffer having changed from 12+ to 12. > Here, I suspect there's a bug in the native compilation of > desktop-buffer. The problem here is that (func-arity 'desktop-buffer) returns (12 . 12) on a byte compiled desktop.elc, but (12 . many) on the corresponding .eln file. This (12 . many) must be regarded as a bug, since there are no &rest parameters in desktop-buffer. I propose a minor amendment to the definition of MANY, such that it will mean "there are &rest parameters", rather than "the calling convention is with nargs + *args". I have implemented this, and my patch is below. What I want to ask you to check is that in the native compiler, when declare_imported_func encounters a function with, say, exactly 12 arguments, it will throw an error. I think this is actually correct, since the compiler cannot know whether this function uses the subr calling convention of nargs + *args, or the byte coded convention of pushing the 12 arguments individually onto the stack. Is throwing this error a good idea? Thanks! Here's my proposed patch: Amend the meaning of "MANY"; this solves bug #58739 Make "MANY" mean there are &rest parameters. The previous definition left ambiguous whether a subr with over 8 parameters also had &rest parameters. * lisp/emacs-lisp/comp.el (comp-prepare-args-for-top-level): Return the number of parameters rather than `many' when this is a fixed number over 8. * src/comp.c (declare_imported_func): Throw an error when an imported function has a fixed number over 8 of parameters, since we cannot compile a call to this which will work for both byte code and native code. * src/eval.c (eval_sub, funcall_subr): Where we test for MANY, also test the number of arguments against 8. (funcall_subr): Resolve the previous inability to call subr's with a fixed number over 8 of arguments. diff --git a/lisp/emacs-lisp/comp.el b/lisp/emacs-lisp/comp.el index 5a05fe4854..f7e118616d 100644 --- a/lisp/emacs-lisp/comp.el +++ b/lisp/emacs-lisp/comp.el @@ -2057,9 +2057,10 @@ comp-prepare-args-for-top-level "Lexically-scoped FUNCTION." (let ((args (comp-func-l-args function))) (cons (make-comp-mvar :constant (comp-args-base-min args)) - (make-comp-mvar :constant (if (comp-args-p args) - (comp-args-max args) - 'many))))) + (make-comp-mvar :constant (cond + ((comp-args-p args) (comp-args-max args)) + ((comp-nargs-rest args) 'many) + (t (comp-nargs-nonrest args))))))) (cl-defmethod comp-prepare-args-for-top-level ((function comp-func-d)) "Dynamically scoped FUNCTION." diff --git a/src/comp.c b/src/comp.c index 14012634cc..8c9db20e72 100644 --- a/src/comp.c +++ b/src/comp.c @@ -999,6 +999,13 @@ declare_imported_func (Lisp_Object subr_sym, gcc_jit_type *ret_type, types = SAFE_ALLOCA (nargs * sizeof (* types)); types[0] = comp.lisp_obj_type; } + else if (nargs > 8) + /* The calling convention for a function with a fixed number of + arguments greater than eight is different between a native + compiled function and a byte compiled function. Thus we + cannot safely compile it with the native compiler. */ + signal_error ("Imported function has too many arguments safely to compile natively", + subr_sym); else if (!types) { types = SAFE_ALLOCA (nargs * sizeof (* types)); diff --git a/src/eval.c b/src/eval.c index 8810136c04..495dbb53b5 100644 --- a/src/eval.c +++ b/src/eval.c @@ -2433,7 +2433,9 @@ eval_sub (Lisp_Object form) else if (XSUBR (fun)->max_args == UNEVALLED) val = (XSUBR (fun)->function.aUNEVALLED) (args_left); - else if (XSUBR (fun)->max_args == MANY) + else if (XSUBR (fun)->max_args == MANY + || XSUBR (fun)->max_args > 8) + { /* Pass a vector of evaluated arguments. */ Lisp_Object *vals; @@ -2996,7 +2998,8 @@ funcall_subr (struct Lisp_Subr *subr, ptrdiff_t numargs, Lisp_Object *args) if (numargs >= subr->min_args) { /* Conforming call to finite-arity subr. */ - if (numargs <= subr->max_args) + if (numargs <= subr->max_args + && subr->max_args <= 8) { Lisp_Object argbuf[8]; Lisp_Object *a; @@ -3032,15 +3035,13 @@ funcall_subr (struct Lisp_Subr *subr, ptrdiff_t numargs, Lisp_Object *args) return subr->function.a8 (a[0], a[1], a[2], a[3], a[4], a[5], a[6], a[7]); default: - /* If a subr takes more than 8 arguments without using MANY - or UNEVALLED, we need to extend this function to support it. - Until this is done, there is no way to call the function. */ - emacs_abort (); + emacs_abort (); /* Can't happen. */ } } /* Call to n-adic subr. */ - if (subr->max_args == MANY) + if (subr->max_args == MANY + || subr->max_args > 8) return subr->function.aMANY (numargs, args); } diff --git a/src/lisp.h b/src/lisp.h index 5f6721595c..881548ead4 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -3187,10 +3187,11 @@ CHECK_SUBR (Lisp_Object x) `minargs' should be a number, the minimum number of arguments allowed. `maxargs' should be a number, the maximum number of arguments allowed, or else MANY or UNEVALLED. - MANY means pass a vector of evaluated arguments, - in the form of an integer number-of-arguments - followed by the address of a vector of Lisp_Objects - which contains the argument values. + MANY means there are &rest arguments. Here we pass a vector + of evaluated arguments in the form of an integer + number-of-arguments followed by the address of a vector of + Lisp_Objects which contains the argument values. (We also use + this convention when calling a subr with more than 8 parameters.) UNEVALLED means pass the list of unevaluated arguments `intspec' says how interactive arguments are to be fetched. If the string starts with a `(', `intspec' is evaluated and the resulting -- Alan Mackenzie (Nuremberg, Germany). From unknown Mon Jun 23 07:50:17 2025 X-Loop: help-debbugs@gnu.org Subject: bug#58739: Lack of error message about number of args (?native compilation?) Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 25 Oct 2022 20:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: 58739@debbugs.gnu.org Received: via spool by 58739-submit@debbugs.gnu.org id=B58739.166672894420584 (code B ref 58739); Tue, 25 Oct 2022 20:16:02 +0000 Received: (at 58739) by debbugs.gnu.org; 25 Oct 2022 20:15:44 +0000 Received: from localhost ([127.0.0.1]:52483 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1onQKt-0005Lw-Hf for submit@debbugs.gnu.org; Tue, 25 Oct 2022 16:15:43 -0400 Received: from mx.sdf.org ([205.166.94.24]:56426) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1onQKr-0005Lm-3O for 58739@debbugs.gnu.org; Tue, 25 Oct 2022 16:15:41 -0400 Received: from ma.sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 29PKFcWI019884 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 25 Oct 2022 20:15:38 GMT From: Andrea Corallo In-Reply-To: (Alan Mackenzie's message of "Mon, 24 Oct 2022 16:41:25 +0000") References: Date: Tue, 25 Oct 2022 20:15:38 +0000 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Alan Mackenzie writes: > Hello, Andrea. > > On Sun, Oct 23, 2022 at 12:12:49 +0000, Alan Mackenzie wrote: >> Hello, Emacs. > >> Firstly, note that the function desktop-buffer has exactly 12 >> parameters. > >> With an up to date Emacs 29: > >> (i) emacs -Q >> (ii) M-x load-library RET desktop RET. >> (iii) M-x disassemble RET desktop-buffer. > >> Note that this is native code. > >> (iv) M-: (desktop-buffer 1 2 3 4 5 6 7 8 9 10 11 12 13) RET > >> This gives an error message about 4 not being a list. What it ought to >> do is instead throw an error about the number of arguments. This is a >> bug. > >> (v) M-x load-file RET /path/to/emacs/lisp/desktop.elc. >> (vi) M-x disassemble RET desktop-buffer. > >> Note that we now have byte compiled code. > >> (vii) M-: (desktop-buffer 1 2 3 4 5 6 7 8 9 10 11 12 13) RET > >> We now get a correct error message about the numbere of arguments. > >> As a matter of interest, I noticed this bug while byte-compiling >> desktop.el inside Emacs. It gave a warning message about the number of >> parameters to desktop-buffer having changed from 12+ to 12. > >> Here, I suspect there's a bug in the native compilation of >> desktop-buffer. > > The problem here is that (func-arity 'desktop-buffer) returns (12 . 12) on a > byte compiled desktop.elc, but (12 . many) on the corresponding .eln file. > This (12 . many) must be regarded as a bug, since there are no &rest > parameters in desktop-buffer. > > I propose a minor amendment to the definition of MANY, such that it will > mean "there are &rest parameters", rather than "the calling convention > is with nargs + *args". I have implemented this, and my patch is below. > > What I want to ask you to check is that in the native compiler, when > declare_imported_func encounters a function with, say, exactly 12 > arguments, it will throw an error. I think this is actually correct, > since the compiler cannot know whether this function uses the subr > calling convention of nargs + *args, or the byte coded convention of > pushing the 12 arguments individually onto the stack. Is throwing this > error a good idea? Hi Alan, to me this fix looks like a good idea (assuming changing the definition of MANY is acceptable). I think also that throwing the error in 'declare_imported_func' is okay at this point. Just two small nits (forgive me please :) : > Thanks! > > Here's my proposed patch: [...] > } > + else if (nargs > 8) > + /* The calling convention for a function with a fixed number of > + arguments greater than eight is different between a native ^^^ I think this should be aligned with the initial 'The' > + compiled function and a byte compiled function. Thus we > + cannot safely compile it with the native compiler. */ > + signal_error ("Imported function has too many arguments safely to compile natively", I think we should break this string to stay within 78 characters (see CONTRIBUTE). > + subr_sym); > else if (!types) > { > types = SAFE_ALLOCA (nargs * sizeof (* types)); > diff --git a/src/eval.c b/src/eval.c > index 8810136c04..495dbb53b5 100644 > --- a/src/eval.c > +++ b/src/eval.c > @@ -2433,7 +2433,9 @@ eval_sub (Lisp_Object form) > > else if (XSUBR (fun)->max_args == UNEVALLED) > val = (XSUBR (fun)->function.aUNEVALLED) (args_left); > - else if (XSUBR (fun)->max_args == MANY) > + else if (XSUBR (fun)->max_args == MANY > + || XSUBR (fun)->max_args > 8) > + > { > /* Pass a vector of evaluated arguments. */ > Lisp_Object *vals; > @@ -2996,7 +2998,8 @@ funcall_subr (struct Lisp_Subr *subr, ptrdiff_t numargs, Lisp_Object *args) Likewise > if (numargs >= subr->min_args) > { > /* Conforming call to finite-arity subr. */ > - if (numargs <= subr->max_args) > + if (numargs <= subr->max_args > + && subr->max_args <= 8) > { > Lisp_Object argbuf[8]; > Lisp_Object *a; > @@ -3032,15 +3035,13 @@ funcall_subr (struct Lisp_Subr *subr, ptrdiff_t numargs, Lisp_Object *args) Likewise > return subr->function.a8 (a[0], a[1], a[2], a[3], a[4], a[5], > a[6], a[7]); [...] Thanks for the patch! Andrea From unknown Mon Jun 23 07:50:17 2025 X-Loop: help-debbugs@gnu.org Subject: bug#58739: Lack of error message about number of args (?native compilation?) Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 Oct 2022 12:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Andrea Corallo Cc: 58739@debbugs.gnu.org Received: via spool by 58739-submit@debbugs.gnu.org id=B58739.166704509127503 (code B ref 58739); Sat, 29 Oct 2022 12:05:02 +0000 Received: (at 58739) by debbugs.gnu.org; 29 Oct 2022 12:04:51 +0000 Received: from localhost ([127.0.0.1]:35083 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ooka2-00079X-W5 for submit@debbugs.gnu.org; Sat, 29 Oct 2022 08:04:51 -0400 Received: from mx3.muc.de ([193.149.48.5]:38546) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ookZy-00079G-WB for 58739@debbugs.gnu.org; Sat, 29 Oct 2022 08:04:49 -0400 Received: (qmail 350 invoked by uid 3782); 29 Oct 2022 14:04:40 +0200 Received: from acm.muc.de (p4fe15996.dip0.t-ipconnect.de [79.225.89.150]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 29 Oct 2022 14:04:40 +0200 Received: (qmail 7489 invoked by uid 1000); 29 Oct 2022 12:04:36 -0000 Date: Sat, 29 Oct 2022 12:04:36 +0000 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Andrea. On Tue, Oct 25, 2022 at 20:15:38 +0000, Andrea Corallo wrote: > Alan Mackenzie writes: > > On Sun, Oct 23, 2022 at 12:12:49 +0000, Alan Mackenzie wrote: [ .... ] > >> As a matter of interest, I noticed this bug while byte-compiling > >> desktop.el inside Emacs. It gave a warning message about the number of > >> parameters to desktop-buffer having changed from 12+ to 12. > >> Here, I suspect there's a bug in the native compilation of > >> desktop-buffer. > > The problem here is that (func-arity 'desktop-buffer) returns (12 . 12) on a > > byte compiled desktop.elc, but (12 . many) on the corresponding .eln file. > > This (12 . many) must be regarded as a bug, since there are no &rest > > parameters in desktop-buffer. > > I propose a minor amendment to the definition of MANY, such that it will > > mean "there are &rest parameters", rather than "the calling convention > > is with nargs + *args". I have implemented this, and my patch is below. > > What I want to ask you to check is that in the native compiler, when > > declare_imported_func encounters a function with, say, exactly 12 > > arguments, it will throw an error. I think this is actually correct, > > since the compiler cannot know whether this function uses the subr > > calling convention of nargs + *args, or the byte coded convention of > > pushing the 12 arguments individually onto the stack. Is throwing this > > error a good idea? > Hi Alan, > to me this fix looks like a good idea (assuming changing the definition > of MANY is acceptable). We'll see what Eli says. > I think also that throwing the error in 'declare_imported_func' is okay > at this point. Apologies at this point. I should have produced an error from this before bothering you. I was unable to produce such an error, and I've spent the last few days understanding what happens here, with this result: A call from a native compiled function is always in the form nargs + *args, regardless of whether there are more than 8 arguments or not. More accurately, the call to an unknown type of function (.eln/.elc/.el) puts the function (in some form, I don't know exactly what) at element 0 of *args, and the arguments themselves starting at element 1 of *args. It then calls Ffuncall (or something like it). When the called function is a byte-code function, further down the call stack exec_byte_code gets called with this (nargs + 1) + *args. exec_byte_code then pushes the arguments onto the stack before interpreting the byte code. So this "problem" with the native compiler not knowing what call sequence to generate isn't a problem at all. It's all dealt with at run time. No doubt this slows down Emacs quite a bit, but it's safe. So I'll take that bit out of my patch, and commit the rest of it to master, and see what happens from there. > Just two small nits (forgive me please :) : Thanks for these, I've incorporated them into my amended source code. [ .... ] > Thanks for the patch! > Andrea -- Alan Mackenzie (Nuremberg, Germany). From unknown Mon Jun 23 07:50:17 2025 X-Loop: help-debbugs@gnu.org Subject: bug#58739: Lack of error message about number of args (?native compilation?) Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 Oct 2022 12:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: 58739@debbugs.gnu.org, akrl@sdf.org Received: via spool by 58739-submit@debbugs.gnu.org id=B58739.166704772531877 (code B ref 58739); Sat, 29 Oct 2022 12:49:02 +0000 Received: (at 58739) by debbugs.gnu.org; 29 Oct 2022 12:48:45 +0000 Received: from localhost ([127.0.0.1]:35126 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oolGX-0008I5-6F for submit@debbugs.gnu.org; Sat, 29 Oct 2022 08:48:45 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45782) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oolGU-0008Hs-J8 for 58739@debbugs.gnu.org; Sat, 29 Oct 2022 08:48:43 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oolGO-0005Ve-SW; Sat, 29 Oct 2022 08:48:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=8semC6wMvLq/t/WFPvJfV0a0Jsv8cLjxzMx3Lbrl9C0=; b=htaLzyh8A/Sz n9CegjNjgHZUkYAIdvosLTry8DuuwSTP0t/Nw1wxpFi83NztCi6ytVCxpBnWsh/T3nY4RbhOqUBLW qWT152SV4cKDwtzDLqTpkMN3R5WfIeKeIlDMY6EOIid0jcr7CI8jn71M5bswxZMSxuzK1bSHOjnvL S0sNGohNsNoJ2bs5ChaHuXUGFhElgw1kZTNxwjCk1evehKDNrRjOCLvdUQumK8i+GbIh0VuRokAYe BoWv23/cIKAMNm2zMaer4e1RoBoAemGDSl1DESCFn3kpfj9/KCjs6EhXxJcaJdBAdW3Ig0Z4BWB66 PbbgnZWi8oQWbYbwN/H3iA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oolGO-0001CD-Bl; Sat, 29 Oct 2022 08:48:36 -0400 Date: Sat, 29 Oct 2022 15:48:35 +0300 Message-Id: <831qqqiyn0.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Alan Mackenzie on Sat, 29 Oct 2022 12:04:36 +0000) References: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 58739@debbugs.gnu.org > Date: Sat, 29 Oct 2022 12:04:36 +0000 > From: Alan Mackenzie > > > to me this fix looks like a good idea (assuming changing the definition > > of MANY is acceptable). > > We'll see what Eli says. About what, may I ask? From unknown Mon Jun 23 07:50:17 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Alan Mackenzie Subject: bug#58739: closed (Re: bug#58739: Fixed) Message-ID: References: X-Gnu-PR-Message: they-closed 58739 X-Gnu-PR-Package: emacs Reply-To: 58739@debbugs.gnu.org Date: Sat, 29 Oct 2022 13:33:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1667050382-3639-1" This is a multi-part message in MIME format... ------------=_1667050382-3639-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #58739: Lack of error message about number of args (?native compilation?) which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 58739@debbugs.gnu.org. --=20 58739: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D58739 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1667050382-3639-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 58739-done) by debbugs.gnu.org; 29 Oct 2022 13:32:26 +0000 Received: from localhost ([127.0.0.1]:35162 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oolwo-0000vo-8z for submit@debbugs.gnu.org; Sat, 29 Oct 2022 09:32:26 -0400 Received: from mx3.muc.de ([193.149.48.5]:41174) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oolwl-0000vY-Rf for 58739-done@debbugs.gnu.org; Sat, 29 Oct 2022 09:32:25 -0400 Received: (qmail 29022 invoked by uid 3782); 29 Oct 2022 15:32:17 +0200 Received: from acm.muc.de (p4fe15996.dip0.t-ipconnect.de [79.225.89.150]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 29 Oct 2022 15:32:17 +0200 Received: (qmail 32729 invoked by uid 1000); 29 Oct 2022 13:32:13 -0000 Date: Sat, 29 Oct 2022 13:32:13 +0000 To: 58739-done@debbugs.gnu.org Subject: Re: bug#58739: Fixed Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58739-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Bug fixed. -- Alan Mackenzie (Nuremberg, Germany). ------------=_1667050382-3639-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 23 Oct 2022 12:13:10 +0000 Received: from localhost ([127.0.0.1]:43803 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1omZqo-0005TN-Ef for submit@debbugs.gnu.org; Sun, 23 Oct 2022 08:13:10 -0400 Received: from lists.gnu.org ([209.51.188.17]:50268) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1omZql-0005TF-SR for submit@debbugs.gnu.org; Sun, 23 Oct 2022 08:13:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1omZql-0006Y9-7d for bug-gnu-emacs@gnu.org; Sun, 23 Oct 2022 08:13:07 -0400 Received: from mx3.muc.de ([193.149.48.5]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1omZqj-0007oY-2T for bug-gnu-emacs@gnu.org; Sun, 23 Oct 2022 08:13:06 -0400 Received: (qmail 58759 invoked by uid 3782); 23 Oct 2022 14:12:49 +0200 Received: from acm.muc.de (p2e5d5154.dip0.t-ipconnect.de [46.93.81.84]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 23 Oct 2022 14:12:49 +0200 Received: (qmail 24445 invoked by uid 1000); 23 Oct 2022 12:12:49 -0000 Date: Sun, 23 Oct 2022 12:12:49 +0000 To: bug-gnu-emacs@gnu.org Subject: Lack of error message about number of args (?native compilation?) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.5; envelope-from=acm@muc.de; helo=mx3.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) Hello, Emacs. Firstly, note that the function desktop-buffer has exactly 12 parameters. With an up to date Emacs 29: (i) emacs -Q (ii) M-x load-library RET desktop RET. (iii) M-x disassemble RET desktop-buffer. Note that this is native code. (iv) M-: (desktop-buffer 1 2 3 4 5 6 7 8 9 10 11 12 13) RET This gives an error message about 4 not being a list. What it ought to do is instead throw an error about the number of arguments. This is a bug. (v) M-x load-file RET /path/to/emacs/lisp/desktop.elc. (vi) M-x disassemble RET desktop-buffer. Note that we now have byte compiled code. (vii) M-: (desktop-buffer 1 2 3 4 5 6 7 8 9 10 11 12 13) RET We now get a correct error message about the numbere of arguments. As a matter of interest, I noticed this bug while byte-compiling desktop.el inside Emacs. It gave a warning message about the number of parameters to desktop-buffer having changed from 12+ to 12. Here, I suspect there's a bug in the native compilation of desktop-buffer. -- Alan Mackenzie (Nuremberg, Germany). ------------=_1667050382-3639-1-- From unknown Mon Jun 23 07:50:17 2025 X-Loop: help-debbugs@gnu.org Subject: bug#58739: Lack of error message about number of args (?native compilation?) Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 Oct 2022 16:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 58739@debbugs.gnu.org, akrl@sdf.org Received: via spool by 58739-submit@debbugs.gnu.org id=B58739.166705947427859 (code B ref 58739); Sat, 29 Oct 2022 16:05:01 +0000 Received: (at 58739) by debbugs.gnu.org; 29 Oct 2022 16:04:34 +0000 Received: from localhost ([127.0.0.1]:36430 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oooK1-0007FH-MJ for submit@debbugs.gnu.org; Sat, 29 Oct 2022 12:04:33 -0400 Received: from mx3.muc.de ([193.149.48.5]:45648) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oooK0-0007F1-9V for 58739@debbugs.gnu.org; Sat, 29 Oct 2022 12:04:33 -0400 Received: (qmail 79873 invoked by uid 3782); 29 Oct 2022 18:04:26 +0200 Received: from acm.muc.de (p4fe15996.dip0.t-ipconnect.de [79.225.89.150]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 29 Oct 2022 18:04:26 +0200 Received: (qmail 23279 invoked by uid 1000); 29 Oct 2022 16:04:22 -0000 Date: Sat, 29 Oct 2022 16:04:22 +0000 Message-ID: References: <831qqqiyn0.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <831qqqiyn0.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, Oct 29, 2022 at 15:48:35 +0300, Eli Zaretskii wrote: > > Cc: 58739@debbugs.gnu.org > > Date: Sat, 29 Oct 2022 12:04:36 +0000 > > From: Alan Mackenzie > > > to me this fix looks like a good idea (assuming changing the definition > > > of MANY is acceptable). > > We'll see what Eli says. > About what, may I ask? My patch for this bug. As a quick summary, the cause of spurious warning messages in the byte compiler was subr-arity returning (12 . many) rather than the correct (12 . 12) for a native compiled function with exactly 12 parameters. I've corrected this, by making subr-arity return (12 . 12), and I committed the patch earlier on this afternoon. In the process, MANY came to be defined to mean "has &rest parameters". I think you'll be interested in the patch. -- Alan Mackenzie (Nuremberg, Germany). From unknown Mon Jun 23 07:50:17 2025 X-Loop: help-debbugs@gnu.org Subject: bug#58739: Lack of error message about number of args (?native compilation?) Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 31 Oct 2022 13:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: 58739@debbugs.gnu.org Received: via spool by 58739-submit@debbugs.gnu.org id=B58739.166722212526620 (code B ref 58739); Mon, 31 Oct 2022 13:16:01 +0000 Received: (at 58739) by debbugs.gnu.org; 31 Oct 2022 13:15:25 +0000 Received: from localhost ([127.0.0.1]:39764 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1opUdR-0006uA-9r for submit@debbugs.gnu.org; Mon, 31 Oct 2022 09:15:25 -0400 Received: from mx.sdf.org ([205.166.94.24]:49594) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1opUdM-0006bd-0X for 58739@debbugs.gnu.org; Mon, 31 Oct 2022 09:15:23 -0400 Received: from ma.sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 29VDFIKG020623 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 31 Oct 2022 13:15:18 GMT From: Andrea Corallo In-Reply-To: (Alan Mackenzie's message of "Sat, 29 Oct 2022 12:04:36 +0000") References: Date: Mon, 31 Oct 2022 13:15:18 +0000 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Alan Mackenzie writes: > Hello, Andrea. > > On Tue, Oct 25, 2022 at 20:15:38 +0000, Andrea Corallo wrote: >> Alan Mackenzie writes: > >> > On Sun, Oct 23, 2022 at 12:12:49 +0000, Alan Mackenzie wrote: > > [ .... ] > >> >> As a matter of interest, I noticed this bug while byte-compiling >> >> desktop.el inside Emacs. It gave a warning message about the number of >> >> parameters to desktop-buffer having changed from 12+ to 12. > >> >> Here, I suspect there's a bug in the native compilation of >> >> desktop-buffer. > >> > The problem here is that (func-arity 'desktop-buffer) returns (12 . 12) on a >> > byte compiled desktop.elc, but (12 . many) on the corresponding .eln file. >> > This (12 . many) must be regarded as a bug, since there are no &rest >> > parameters in desktop-buffer. > >> > I propose a minor amendment to the definition of MANY, such that it will >> > mean "there are &rest parameters", rather than "the calling convention >> > is with nargs + *args". I have implemented this, and my patch is below. > >> > What I want to ask you to check is that in the native compiler, when >> > declare_imported_func encounters a function with, say, exactly 12 >> > arguments, it will throw an error. I think this is actually correct, >> > since the compiler cannot know whether this function uses the subr >> > calling convention of nargs + *args, or the byte coded convention of >> > pushing the 12 arguments individually onto the stack. Is throwing this >> > error a good idea? > >> Hi Alan, > >> to me this fix looks like a good idea (assuming changing the definition >> of MANY is acceptable). > > We'll see what Eli says. > >> I think also that throwing the error in 'declare_imported_func' is okay >> at this point. > > Apologies at this point. I should have produced an error from this > before bothering you. I was unable to produce such an error, and I've > spent the last few days understanding what happens here, with this > result: > > A call from a native compiled function is always in the form nargs + > *args, regardless of whether there are more than 8 arguments or not. > More accurately, the call to an unknown type of function (.eln/.elc/.el) > puts the function (in some form, I don't know exactly what) at element 0 > of *args, and the arguments themselves starting at element 1 of *args. > It then calls Ffuncall (or something like it). > > When the called function is a byte-code function, further down the call > stack exec_byte_code gets called with this (nargs + 1) + *args. > exec_byte_code then pushes the arguments onto the stack before > interpreting the byte code. > > So this "problem" with the native compiler not knowing what call sequence > to generate isn't a problem at all. It's all dealt with at run time. No > doubt this slows down Emacs quite a bit, but it's safe. > > So I'll take that bit out of my patch, and commit the rest of it to > master, and see what happens from there. Hi Alan, That's correct. As you prefer, we could also keep it as assertion. Thanks Andrea