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: Emacs port to gcc -fcheck-pointer-bounds Date: Wed, 13 Dec 2017 11:39:53 -0800 Organization: UCLA Computer Science Department Message-ID: <90e8ba59-bbff-b1fb-9a99-c4426fa8d2ac@cs.ucla.edu> References: <83indhwcx5.fsf@gnu.org> <83k1xwuwq3.fsf@gnu.org> <83efo2trwu.fsf@gnu.org> <83374hthe6.fsf@gnu.org> <1da23740-5960-9358-a46c-3b078428cb6c@cs.ucla.edu> <83indavbu6.fsf@gnu.org> <7172f906-7a58-9b60-a5c6-57c47cbcf989@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1513194008 10496 195.159.176.226 (13 Dec 2017 19:40:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 13 Dec 2017 19:40:08 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 13 20:40:04 2017 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 1ePCss-0002Sj-GT for ged-emacs-devel@m.gmane.org; Wed, 13 Dec 2017 20:40:02 +0100 Original-Received: from localhost ([::1]:37260 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ePCsz-0004Cd-KE for ged-emacs-devel@m.gmane.org; Wed, 13 Dec 2017 14:40:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53694) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ePCsq-0004At-4S for emacs-devel@gnu.org; Wed, 13 Dec 2017 14:40:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ePCsm-0000AN-6y for emacs-devel@gnu.org; Wed, 13 Dec 2017 14:40:00 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:33132) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ePCsm-00009W-01 for emacs-devel@gnu.org; Wed, 13 Dec 2017 14:39:56 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9CDC5161451; Wed, 13 Dec 2017 11:39:54 -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 VC9MXfYGrzlF; Wed, 13 Dec 2017 11:39:53 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id D5BB716147C; Wed, 13 Dec 2017 11:39:53 -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 VqrbeiNZJKzV; Wed, 13 Dec 2017 11:39:53 -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 BBA8516143F; Wed, 13 Dec 2017 11:39:53 -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.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:221018 Archived-At: On 12/13/2017 11:17 AM, Stefan Monnier wrote: >> The fake pointer catches (at compile-time) common faults like the one >> the >> attached patch fixes, where an int was passed where a Lisp_Object was >> expected. These are the most important faults that >> --enable-check-lisp-object-type catches. > ... it doesn't catch things like `x + n` since adding a constant to a > pointer is also a valid operation Actually it catches even (x + n), because Lisp_Object is 'union Lisp_X *', and the union type is deliberately incomplete so the C compiler does not know its size and cannot multiply n by sizeof (union Lisp_X). The C Standard requires a diagnostic for (x + n) and practice compilers invariably issue at least a warning. There are some things it doesn't catch. Most of these (e.g., 'Lisp_Object x = 0;', or 'Lisp Object x = FOO, y = BAR; return x == y;') are harmless annoyances. The only worrisome thing not caught is converting between void * and Lisp_Object, e.g., 'Lisp_Object z = malloc (n);'. However, to my mind it's overkill to --enable-check-lisp-object-type by default just to catch this, as void * is dangerous with every C pointer type and there's little extra harm to making it dangerous with Lisp_Object too. > Maybe we can turn it into a no-op. Yes, that's my thought too.