From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c Date: Tue, 27 Aug 2019 13:15:12 +0300 Message-ID: <83ftlmewy7.fsf@gnu.org> 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> <9d22dab3-e353-2401-0de3-6fc149e9e09f@cs.ucla.edu> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="123885"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 27 12:16:30 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 1i2YWc-000W7w-Gw for ged-emacs-devel@m.gmane.org; Tue, 27 Aug 2019 12:16:30 +0200 Original-Received: from localhost ([::1]:49094 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2YWa-0005nt-Az for ged-emacs-devel@m.gmane.org; Tue, 27 Aug 2019 06:16:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56268) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2YVK-0005mU-40 for emacs-devel@gnu.org; Tue, 27 Aug 2019 06:15:11 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55738) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i2YVJ-0005b7-Ol; Tue, 27 Aug 2019 06:15:09 -0400 Original-Received: from [176.228.60.248] (port=2083 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i2YVJ-0002wO-5T; Tue, 27 Aug 2019 06:15:09 -0400 In-reply-to: <9d22dab3-e353-2401-0de3-6fc149e9e09f@cs.ucla.edu> (message from Paul Eggert on Tue, 27 Aug 2019 02:28:42 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:239614 Archived-At: > Cc: emacs-devel@gnu.org > From: Paul Eggert > Date: Tue, 27 Aug 2019 02:28:42 -0700 > > 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. Do you have a guess why GCC might get lost in that code? > > And how should GCC know that? > > GCC could use the same sort of reasoning I used. Which reasoning is that? You haven't presented your reasoning for XParseGeometry, AFAICT. You presented reasoning for some other code, which you consider similar. > 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. No, UNINIT is for you to be able to use your tools of choice, and perhaps also to cater to your personal stylistic preferences. I consider an initialization with a comment explaining why to be a better alternative, whether the warning is real or a false alarm.