From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [External] : Re: Question about native compilation (bug?) Date: Thu, 27 Jul 2023 22:11:43 +0300 Message-ID: <83bkfxkw40.fsf@gnu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4342"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acorallo@gnu.org, emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jul 27 22:24:10 2023 Return-path: Envelope-to: ged-emacs-devel@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 1qP7Wr-0000uG-G7 for ged-emacs-devel@m.gmane-mx.org; Thu, 27 Jul 2023 22:24:09 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qP6O0-0006Ag-DC; Thu, 27 Jul 2023 15:10:56 -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 1qP6Nz-0006AW-9L for emacs-devel@gnu.org; Thu, 27 Jul 2023 15:10:55 -0400 Original-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 1qP6Ny-0002Yg-H7; Thu, 27 Jul 2023 15:10:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=ZWf4WquuaGIGVvnA0PQd6rS8e+SMNhFdvXfXYvG5LfY=; b=HZZPQWb7GEqu9YWBoiO6 BgZYe78EVqlUEBZfvvAt7J39mEnXk5epAAOYu/f2tzmzEJKsDFlqbp+7Y9UW3gMXG4bnin0blV+bo 2IChMlMQPS8TZz28IIO9VBmHgcouxMpKtyAz1EFi0W53MJqCztvymADinPTYPQ75LOouzmvUkUffC H4F7aH5kG4Vuhtm5rwJ151MgtO3aRpbi3Bv56P+cSZ3zNslgHGvVTrwS4lxoWcfBHaBfC/TDHz+sz +SAThiOQlkM6r9PTnkRsJTyf4VrsBpCgzP1EMR0yU4ApwGvM3GfLc0Y2ber44NHwRuty8S8Yvhptf t6mnMy4BRdvDfQ==; Original-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 1qP6Nx-0006qD-OB; Thu, 27 Jul 2023 15:10:54 -0400 In-Reply-To: (message from Drew Adams on Thu, 27 Jul 2023 18:14:15 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:308175 Archived-At: > From: Drew Adams > CC: "emacs-devel@gnu.org" > Date: Thu, 27 Jul 2023 18:14:15 +0000 > > > > What about my other questions, e.g. wrt fixing this? > > > > I haven't done any recent analysis, from what I remember it is not > > easily fixable. > > > > That said I think is not worth of, redefining primitives is already > > discouraged by the manual and dangerous (more on that later), doing it > > with a different signature it's just kamikaze behavior. > > > > Note also that redefining primitives in Emacs is not only disincouraged, > > but is really not guaranteed to work properly. The redefinition will > > not take effect executing bytecode if the primitive has a dedicated > > byteopcode and it will *not* take effect either for any call to the > > primiteve done form C itself. > > I don't claim to understand all of that, e.g. > primitives that do or don't have dedicated > byteopcodes etc. > > The fact is that it does work for `read-buffer', > except when native compilation is turned on. If we ever decide to give read-buffer a dedicate bytecode op-code, it will stop working. So applications using this are unreliable. > The point is to have compatibility with what > happens with Lisp source code. > > If this can't/won't be fixed, so be it. But it > makes Elisp code with native compilation behave > differently from Elisp code that's either source > or byte-compiled. By doing this you invoke "undefined behavior", whereby you cannot talk about "different behavior" because the behavior is undefined. > If this won't be fixed, or until it is, shouldn't > such incompatibility be called out in the doc? We already advise not to redefine existing functions: Be careful not to redefine existing functions unintentionally. ‘defun’ redefines even primitive functions such as ‘car’ without any hesitation or notification. Emacs does not prevent you from doing this, because redefining a function is sometimes done deliberately, and there is no way to distinguish deliberate redefinition from unintentional redefinition. > Even aside from imagining redefinitions, does > it make sense for a source-code function call > that passes N args to be changed to a call that > passes N args plus M nil args? That's really > what this is about, it seems to me: reproducing > the actual call, as is, instead of adding > explicit nil optional args. We don't do that > with byte compilation, right? Why should we > need to do it with native compilation? Because native code runs natively, not by our interpreter, and thus must have a fixed number of arguments.