all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c
Date: Tue, 27 Aug 2019 02:28:42 -0700	[thread overview]
Message-ID: <9d22dab3-e353-2401-0de3-6fc149e9e09f@cs.ucla.edu> (raw)
In-Reply-To: <83lfvfdoj6.fsf@gnu.org>

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.



  reply	other threads:[~2019-08-27  9:28 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-24  6:14 [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c Eli Zaretskii
2019-08-25  0:52 ` Paul Eggert
2019-08-25  7:13   ` Eli Zaretskii
2019-08-26  6:34     ` Paul Eggert
2019-08-26  7:54       ` Eli Zaretskii
2019-08-26  8:15         ` Paul Eggert
2019-08-26  9:47           ` Eli Zaretskii
2019-08-26 15:21             ` Óscar Fuentes
2019-08-26 16:13               ` Eli Zaretskii
2019-08-26 18:20                 ` Óscar Fuentes
2019-08-26 18:39                   ` Eli Zaretskii
2019-08-26 19:09                     ` Paul Eggert
2019-08-26 19:15                     ` Óscar Fuentes
2019-08-26 19:33                       ` Eli Zaretskii
2019-08-26 19:49                         ` Óscar Fuentes
2019-08-26 22:33                         ` Paul Eggert
2019-08-27  6:12                           ` Eli Zaretskii
2019-08-27  7:28                             ` Paul Eggert
2019-08-27  8:02                               ` Eli Zaretskii
2019-08-27  9:28                                 ` Paul Eggert [this message]
2019-08-27 10:15                                   ` Eli Zaretskii
2019-08-27 12:05                                     ` Paul Eggert
2019-08-27 12:43                                       ` Eli Zaretskii
2019-08-26 18:50             ` Paul Eggert
2019-08-26 18:56               ` Eli Zaretskii
2019-08-26 23:17             ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9d22dab3-e353-2401-0de3-6fc149e9e09f@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.