From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Change module interface to no longer use GMP objects directly. Date: Wed, 20 Nov 2019 13:24:36 -0800 Organization: UCLA Computer Science Department Message-ID: <10cefdff-38ce-438b-881d-15d2fe816a8b@cs.ucla.edu> References: <20191117183828.82379-1-phst@google.com> <089f3d06-e227-27da-c8fe-afcbbbbc934a@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="17990"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 Cc: Philipp Stephani , Stefan Monnier , Emacs developers To: Philipp Stephani Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 20 22:24:51 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 1iXXSz-0004XT-LX for ged-emacs-devel@m.gmane.org; Wed, 20 Nov 2019 22:24:49 +0100 Original-Received: from localhost ([::1]:34534 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iXXSy-00070Q-Co for ged-emacs-devel@m.gmane.org; Wed, 20 Nov 2019 16:24:48 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38338) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iXXSr-00070K-Mi for emacs-devel@gnu.org; Wed, 20 Nov 2019 16:24:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iXXSq-0001al-0m for emacs-devel@gnu.org; Wed, 20 Nov 2019 16:24:41 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:45500) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iXXSp-0001Zk-RF for emacs-devel@gnu.org; Wed, 20 Nov 2019 16:24:39 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E56601600A0; Wed, 20 Nov 2019 13:24:37 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 1iGnu2zzhPu3; Wed, 20 Nov 2019 13:24:37 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 2C4D4160179; Wed, 20 Nov 2019 13:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xmZo_RJF0iEU; Wed, 20 Nov 2019 13:24:37 -0800 (PST) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 07D991600A0; Wed, 20 Nov 2019 13:24:37 -0800 (PST) In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 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:242544 Archived-At: On 11/20/19 1:06 PM, Philipp Stephani wrote: > GMP seems to make a very complex series of choices when selecting the > limb datatype, which we can't and shouldn't replicate. We don't need to replicate GMP's reasoning. We can use a 'configure' time test to use whatever type GMP uses. The emacs-module header could be quite simple, and just use that type (typically unsigned long, but not always) when typedeffing emacs_limb_t. I'll write the configure-time code, so you don't need to worry about implementing it (not that it's hard to write). > copy_string_contents > returns false if and only if it has signaled an error, which is a > quite useful invariant. No, copy_string_contents never returns false. If it signals an error, it does not return. If it returns, it always returns true. It's pretty weird, but there it is. >> I found the guarantee useful in the first function I wrote that >> attempted to use the proposed API, so that's good evidence that it's >> worth documenting. > > I don't think so, it's a very narrow guarantee that we also don't give > for other functions. I don't think any of the other functions need such a guarantee (but if they do, we should provide it). > Each guarantee, however minor, comes with a cost: > we need to document it and stick to it forever. This particular guarantee has so little cost that the cost is not worth worrying about. It's a guarantee we'll never want to violate and there's essentially no cost to sticking to it "forever". I'll write the one-sentence documentation, if that helps.