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: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c Date: Tue, 27 Aug 2019 02:28:42 -0700 Organization: UCLA Computer Science Department Message-ID: <9d22dab3-e353-2401-0de3-6fc149e9e09f@cs.ucla.edu> References: <835zmnjdjm.fsf@gnu.org> <227db16b-17d1-b44b-97b3-e80211415eef@cs.ucla.edu> <831rx9iupo.fsf@gnu.org> <32f9db09-0c04-df03-4bb7-76fe2aa9a88f@cs.ucla.edu> <83tva4fjkz.fsf@gnu.org> <87cb5a0c-bdd8-726c-80ed-92e9f3518a58@cs.ucla.edu> <83o90cfecf.fsf@gnu.org> <87lfvg3qbi.fsf@telefonica.net> <83imqjgb1g.fsf@gnu.org> <87ftln4wm0.fsf@telefonica.net> <83a7bvg4a2.fsf@gnu.org> <87blwb4u2i.fsf@telefonica.net> <835zmjg1re.fsf@gnu.org> <831rx7f863.fsf@gnu.org> <834b9308-5235-be47-1cf8-136bb6f35e48@cs.ucla.edu> <83lfvfdoj6.fsf@gnu.org> 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="184289"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 27 11:29:00 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 1i2Xmd-000lmk-NF for ged-emacs-devel@m.gmane.org; Tue, 27 Aug 2019 11:28:59 +0200 Original-Received: from localhost ([::1]:48684 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2Xmc-0004VH-9c for ged-emacs-devel@m.gmane.org; Tue, 27 Aug 2019 05:28:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49227) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2XmU-0004TJ-FK for emacs-devel@gnu.org; Tue, 27 Aug 2019 05:28:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i2XmS-0007TD-Ry for emacs-devel@gnu.org; Tue, 27 Aug 2019 05:28:49 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:52530) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i2XmQ-0007RK-Bx; Tue, 27 Aug 2019 05:28:46 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 253481600CB; Tue, 27 Aug 2019 02:28:44 -0700 (PDT) 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 ozrxpvOGN9aP; Tue, 27 Aug 2019 02:28:43 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 3E7DF1600E6; Tue, 27 Aug 2019 02:28:43 -0700 (PDT) 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 ieiSAm39evcf; Tue, 27 Aug 2019 02:28:43 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 174AA1600CB; Tue, 27 Aug 2019 02:28:43 -0700 (PDT) In-Reply-To: <83lfvfdoj6.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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:239612 Archived-At: Eli Zaretskii wrote: > How do you know whether (geometry & XValue) is nonzero in each > relevant use case? By reading the source code. Although it's simple enough, here's a very detailed analysis to make sure we're on the same page. In Fx_parse_geometry, every use of the local variable x must be preceded by an initialization of x, because every use is guarded by (geometry & XValue) and this test succeeds only when x is initialized. The initialization is done not directly by Fx_parse_geometry, but by a function that Fx_parse_geometry calls. This sort of thing is common. E.g., image_create_bitmap_from_file does this: 490 unsigned int width, height; ... 517 result = XReadBitmapFile (FRAME_X_DISPLAY (f), FRAME_X_DRAWABLE (f), 518 filename, &width, &height, &bitmap, &xhot, &yhot); 519 if (result != BitmapSuccess) 520 return -1; ... 528 dpyinfo->bitmaps[id - 1].height = height; 529 dpyinfo->bitmaps[id - 1].width = width; Here too there is no path through the code where 'width' and 'height' can be used before being set, because every use of 'width' and 'height' is guarded by (result == BitmapSuccess) and this test succeeds only when 'width' and 'height' are initialized. Hence image_create_bitmap_from_file need not initialize 'width' and 'height' in line 490, since XReadBitmapFile initializes them when it returns BitmapSuccess. Also, 'width' and 'height' should not be marked with UNINIT here since GCC does not warn here. GCC's lack of warning here does not mean that GCC knows that width and height are initialized: all it means is that GCC's heuristics for warnings do not elicit a warning here. There are two reasons that omitting UNINIT causes GCC to warn about Fx_parse_geometry but not image_create_bitmap_from_file. First, under MS-Windows GCC has access to the source code of the initialization function XParseGeometry that Fx_parse_geometry calls, whereas under X Windows GCC lacks access to the source code of the initialization function XReadBitmapFile that image_create_bitmap_from_file calls (I am assuming typical builds without fancy link-time optimization). Second, GCC does not fully grok the source code of MS-Windows XParseGeometry; GCC gets lost and thinks that there's a path through Fx_parse_geometry + XParseGeometry that will use Fx_parse_geometry's x without initializing it, even though there is no such path. > And how should GCC know that? GCC could use the same sort of reasoning I used. And perhaps some future version of GCC will do that. But in the meantime GCC gives a false alarm, so UNINIT is warranted here. UNINIT is precisely for this sort of situation: the programmer knows that a variable need not be initialized, but GCC falsely warns about the lack of initialization.