From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#58739: Lack of error message about number of args (?native compilation?) Date: Sat, 29 Oct 2022 12:04:36 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19664"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 58739@debbugs.gnu.org To: Andrea Corallo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 29 14:05:15 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ookaR-0004s7-AB for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 Oct 2022 14:05:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ookaM-0002IZ-OU; Sat, 29 Oct 2022 08:05:10 -0400 Original-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 1ookaE-0002IC-TN for bug-gnu-emacs@gnu.org; Sat, 29 Oct 2022 08:05:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ookaE-0005EQ-KR for bug-gnu-emacs@gnu.org; Sat, 29 Oct 2022 08:05:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ookaE-00079z-Ew for bug-gnu-emacs@gnu.org; Sat, 29 Oct 2022 08:05:02 -0400 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 58739-submit@debbugs.gnu.org id=B58739.166704509127503 (code B ref 58739); Sat, 29 Oct 2022 12:05:02 +0000 Original-Received: (at 58739) by debbugs.gnu.org; 29 Oct 2022 12:04:51 +0000 Original-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 Original-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 Original-Received: (qmail 350 invoked by uid 3782); 29 Oct 2022 14:04:40 +0200 Original-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 Original-Received: (qmail 7489 invoked by uid 1000); 29 Oct 2022 12:04:36 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "bug-gnu-emacs" Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:246519 Archived-At: 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).