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: Tue, 19 Nov 2019 13:54:25 -0800 Organization: UCLA Computer Science Department Message-ID: 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="7158"; 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 Tue Nov 19 22:54:41 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 1iXBSJ-0001g6-4i for ged-emacs-devel@m.gmane.org; Tue, 19 Nov 2019 22:54:39 +0100 Original-Received: from localhost ([::1]:51918 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iXBSH-0007YS-Os for ged-emacs-devel@m.gmane.org; Tue, 19 Nov 2019 16:54:37 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34607) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iXBSA-0007VC-GG for emacs-devel@gnu.org; Tue, 19 Nov 2019 16:54:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iXBS8-0002GT-V3 for emacs-devel@gnu.org; Tue, 19 Nov 2019 16:54:29 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:37812) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iXBS8-0002Fa-OS for emacs-devel@gnu.org; Tue, 19 Nov 2019 16:54:28 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 951B516027D; Tue, 19 Nov 2019 13:54:26 -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 8Z8B0Fqjka0B; Tue, 19 Nov 2019 13:54:25 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C88791604E7; Tue, 19 Nov 2019 13:54:25 -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 xjqyiHA6Gp5e; Tue, 19 Nov 2019 13:54:25 -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 A9C8D16027D; Tue, 19 Nov 2019 13:54:25 -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:242455 Archived-At: On 11/19/19 1:12 PM, Philipp Stephani wrote: > I'm not against a typedef to provide clearer semantics, but then we'd > also have to define EMACS_LIMB_MAX etc., and I see relatively little > benefit in that (since we can't realistically change it anyway later). I can see a benefit, partly for the cleaner semantics, partly as it lets us arrange for Emacs limbs to be the same size as GMP limbs. If we can't realistically change this later, let's do it the better way the first time. It's easy enough to do; for example, we can define EMACS_LIMB_MAX to be the equivalent of ((emacs_limb_t) -1). > The current "unsigned long" type is identical to mpz_limb_t on most > platforms unsigned long differs from mpz_limb_t on significant-enough platforms (MinGW, Cygwin, ...) that it's worth creating an emacs_limb_t to support those platforms better. > I'm not feeling strongly about the function in isolation, but the > current interface is modeled after the existing copy_string_contents Why does copy_string_contents always return true when it returns? If there's no good reason, let's have the new function use a cleaner API. A flaw in an old function's API does not require us to have a similar flaw in the new one. >> It should document that this size cannot exceed (min (PTRDIFF_MAX, >> SIZE_MAX) / sizeof (emacs_limb_t)).... > > It's true that this allows > callers to use malloc without checking for overflow, and it seems this > already follows from the C standard (can an array with total size > larger than SIZE_MAX exist?), It does not follow from the C standard, as there's no requirement anywhere that Emacs internally must represent each integer as a contiguous array. 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.