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.