From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Change module interface to no longer use GMP objects directly. Date: Thu, 21 Nov 2019 21:31:07 +0100 Message-ID: References: <20191117183828.82379-1-phst@google.com> <089f3d06-e227-27da-c8fe-afcbbbbc934a@cs.ucla.edu> <10cefdff-38ce-438b-881d-15d2fe816a8b@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="216491"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Philipp Stephani , Stefan Monnier , Emacs developers To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 21 21:31:49 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iXt7B-000u8v-AM for ged-emacs-devel@m.gmane.org; Thu, 21 Nov 2019 21:31:45 +0100 Original-Received: from localhost ([::1]:45722 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iXt79-0002aE-Vy for ged-emacs-devel@m.gmane.org; Thu, 21 Nov 2019 15:31:44 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42945) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iXt6n-0002V0-7W for emacs-devel@gnu.org; Thu, 21 Nov 2019 15:31:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iXt6l-0005JG-Uz for emacs-devel@gnu.org; Thu, 21 Nov 2019 15:31:21 -0500 Original-Received: from mail-ot1-x343.google.com ([2607:f8b0:4864:20::343]:36626) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iXt6l-0005J0-OI for emacs-devel@gnu.org; Thu, 21 Nov 2019 15:31:19 -0500 Original-Received: by mail-ot1-x343.google.com with SMTP id f10so4194369oto.3 for ; Thu, 21 Nov 2019 12:31:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yITK9QzVzEluJ5Uf2SXrBM0+kc5b435uh2nGJ7w+9Dc=; b=VbpLnPPfJecqE6nnab1lkKh6wfbkJXjW0XcfZd/gwqrLFqPibfxHcJ+fFWqVfKgQSc JR2mONOwTFSv12iZ/FCOUQRTfl4NZrfOQU6BsF3gCJ3f1lLrro2CiSDcjfik7MbztVxR DGveBndWCcWOJMgW+prFb4Dp5QAFdC2c2q63zbvn5biSpgbm9DOg5PogGgCwQBhpVyUS RMIUlPVD32Yuez1LjENo5exGN3rXQ8EzeVu7SuoDol7Bdaito7e1bp0KCD/EKnmj9/aC ZtTUStUW3l07XjzxkJoaHzOvBytGBPvDljRe9MOl8PgIlewR2WYdhtUKw2DZ9Oo5+c94 EZQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yITK9QzVzEluJ5Uf2SXrBM0+kc5b435uh2nGJ7w+9Dc=; b=qxE+5X9GhekCT2CWQfHqyr1ha04BFK654no7iUDtn+3J4VFuWJjUFtMIuRiWNY8FI5 ZZIVLjPVYL3Fz/WvvhZFATn22fd6QMqjcliJYI2NYtB3eSjQr11lW+BAQ+rFAJQeNi5p UNFeYJ4uiflv2DM2ZdYqlTs8cx58CyoR6MlDbT2jjxBrzo2kbu2EjKU1fkWo4d2zB8p+ 8Vf0aAY4y/Y1zD1M+uqtgVT5BpwRlSSFvug3XljqwydJ87BhhUR2JKemTWTCWwRTuuNi y1RCTgpUe1HMjkSdLc7jMA15J+fX7Fn69JVRvXNLGlqd22Snbx9X/w6OB5CAlLmiuX9j YplA== X-Gm-Message-State: APjAAAXyxaJbnqzrItVWjjnhZzMgdm6ehMZDUWSa+EkqJQajopzWoWyD oNsI2Ws0mm14QVUcjuOhBlJ8OmuUIXtNT5aIdTY= X-Google-Smtp-Source: APXvYqy7YmQQMp3nS729LAzP3Af98S2y9Q2sjKGxtAJilMua1gONWfBV46+qFaz7DkXn1C41Mz8c709VtWfXrY4nH/s= X-Received: by 2002:a9d:38b:: with SMTP id f11mr7715172otf.149.1574368278219; Thu, 21 Nov 2019 12:31:18 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::343 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.org gmane.emacs.devel:242593 Archived-At: Am Do., 21. Nov. 2019 um 02:12 Uhr schrieb Paul Eggert : > > On 11/20/19 1:30 PM, Philipp Stephani wrote: > > > I don't think we can do that either. emacs-module.h has to be > > completely independent from the rest of Emacs. GMP allows changing the > > limb at configure time and depending on some architecture flags, we > > can't allow that. > > I don't see why not, as my proposal would continue to keep > emacs-module.h independent of the rest of Emacs. emacs_limb_t would > merely be a performance hint about GMP, and would not necessarily match > the mp_limb_t that an Emacs module uses. > > Let's take an unusual and extreme example. Suppose Emacs is built with a > a "normal" GMP that uses 64-bit limbs on the current platform, so its > emacs-module.h defines emacs_limb_t to be a 64-bit integer. And suppose > the module author builds with an "unsual" GMP that is configured to use > 32-bit limbs on the current platform. Then emacs_limb_t might be > 'unsigned long long int' while mp_limb_t is 'unsigned int' within module > code. This combination will work: there will be two copies of the GMP > library linked into the executable (the "normal" one and the "unusual" > one), each with its own API and names and calling conventions; Emacs > internals will call one copy and module code will call the other, and > the module code will note that mp_limb_t and emacs_limb_t are different > types and will fall back on the slower mpz_export method to copy integers. > > However, such an example will hardly ever happen. In practice, GMP is > built one way for a particular platform, choosing a platform (which an > Emacs builder needs to do anyway) will choose a particular GMP > implementation, and Emacs's internal use of GMP will match the module's > use so conversion will operate more efficiently. That is not the issue I have in mind. The problem is that emacs-module.h needs to be token-by-token identical for all platforms - it's expected that distributors and users copy it around at will. We can't have it depend on the platform that Emacs was built, or any configure flags used for building Emacs. Even if we allowed emacs-module.h to differ between platforms (which we shouldn't), we still couldn't allow emacs-module.h to contain data derived from configure flags, as then users specifying different configure options could produce wrong/incompatible variants of the header. It's crucial that there's a single canonical emacs-module.h. > > The guarantee itself is fine with me (we should put an assertion into > > the codebase to document it). I just wonder whether it's important > > enough to actually make. > > Yes, I think so. (Admittedly I worry about integer overflow more than > most people do. :-) I definitely worry about it, too, and everyone should. I'm OK with documenting the guarantee since it can prevent users from running into undefined behavior.