From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Fri, 16 Feb 2018 13:09:31 -0800 Organization: UCLA Computer Science Department Message-ID: <2a161cd5-4293-1ccb-9fa8-ba604b83ba4a@cs.ucla.edu> References: <128341f5-4bc1-4c03-980c-c7b2b7e7776e@email.android.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------665BE8A8CC78E2F44094C3F3" X-Trace: blaine.gmane.org 1518815309 29699 195.159.176.226 (16 Feb 2018 21:08:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Feb 2018 21:08:29 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Cc: Andy Moreton , emacs-devel@gnu.org To: Daniel Colascione , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 16 22:08:24 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1emnEu-0006y5-VO for ged-emacs-devel@m.gmane.org; Fri, 16 Feb 2018 22:08:17 +0100 Original-Received: from localhost ([::1]:33060 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emnGx-0001mr-1i for ged-emacs-devel@m.gmane.org; Fri, 16 Feb 2018 16:10:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59698) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emnGG-0001lX-8l for emacs-devel@gnu.org; Fri, 16 Feb 2018 16:09:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1emnGF-0008VE-97 for emacs-devel@gnu.org; Fri, 16 Feb 2018 16:09:40 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:49162) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1emnGA-0008Sy-KS; Fri, 16 Feb 2018 16:09:34 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5BFCD161564; Fri, 16 Feb 2018 13:09:33 -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 Rv4apc4Bev-x; Fri, 16 Feb 2018 13:09:32 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 7BEEA161587; Fri, 16 Feb 2018 13:09:32 -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 zh-cb5WIb-g4; Fri, 16 Feb 2018 13:09:32 -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 5C09B161564; Fri, 16 Feb 2018 13:09:32 -0800 (PST) In-Reply-To: <128341f5-4bc1-4c03-980c-c7b2b7e7776e@email.android.com> 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.21 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:222844 Archived-At: This is a multi-part message in MIME format. --------------665BE8A8CC78E2F44094C3F3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 02/16/2018 12:43 PM, Daniel Colascione wrote: > IMHO, we should enable -Wconversion more broadly. My experience is just the opposite: i.e., that -Wconversion causes more trouble than it cures. The pdumper change to INTEGER_TO_CONS is an example of trouble. The only reason for that change is to work around a compiler bug in GCC that is caused by -Wconversion, a bug that leads to a false alarm. I suggest at least the attached patch, which limits the damage to pdumper.c instead of letting it spread to other Emacs modules. But better yet, I suggest dropping the idea of using -Wconversion even on pdumper.c, as it's counterproductive and in high-quality code almost inevitably leads to further obfuscation like ALLOW_IMPLICIT_CONVERSION and DISALLOW_IMPLICIT_CONVERSION. PS. Double-parens like that shouldn't be needed in macro bodies, as each macro must parenthesize its argument properly anyway. --------------665BE8A8CC78E2F44094C3F3 Content-Type: text/x-patch; name="0001-Better-workaround-for-GCC-bug-with-Wconversion.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-Better-workaround-for-GCC-bug-with-Wconversion.patch" >From 725d6c22f209c96d4ca263ccc173ae77ae7942cf Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 16 Feb 2018 13:06:49 -0800 Subject: [PATCH] Better workaround for GCC bug with -Wconversion * src/lisp.h (INTEGER_TO_CONS): Undo previous change. * src/pdumper.c (DEFINE_TOLISP_FUNC): Disable -Wconversion when INTEGER_TO_CONS is used, too. --- src/lisp.h | 6 +++--- src/pdumper.c | 5 ++++- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/src/lisp.h b/src/lisp.h index 45e8a0d791..6d4635f2a7 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -3568,9 +3568,9 @@ extern Lisp_Object arithcompare (Lisp_Object num1, Lisp_Object num2, itself, or a cons of two or three integers, or if all else fails a float. I should not have side effects. */ #define INTEGER_TO_CONS(i) \ - (! FIXNUM_OVERFLOW_P ((i)) \ - ? make_number ((EMACS_INT) (i)) \ - : EXPR_SIGNED ((i)) ? intbig_to_lisp ((i)) : uintbig_to_lisp ((i))) + (! FIXNUM_OVERFLOW_P (i) \ + ? make_number (i) \ + : EXPR_SIGNED (i) ? intbig_to_lisp (i) : uintbig_to_lisp (i)) extern Lisp_Object intbig_to_lisp (intmax_t); extern Lisp_Object uintbig_to_lisp (uintmax_t); diff --git a/src/pdumper.c b/src/pdumper.c index a05b2c47ce..cc1847356d 100644 --- a/src/pdumper.c +++ b/src/pdumper.c @@ -691,7 +691,10 @@ dump_object_self_representing_p (Lisp_Object object) static Lisp_Object \ fn (type value) \ { \ - return INTEGER_TO_CONS (value); \ + ALLOW_IMPLICIT_CONVERSION; \ + Lisp_Object result = INTEGER_TO_CONS (value); \ + DISALLOW_IMPLICIT_CONVERSION; \ + return result; \ } DEFINE_FROMLISP_FUNC (intmax_t_from_lisp, intmax_t); -- 2.14.3 --------------665BE8A8CC78E2F44094C3F3--