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.
next prev parent 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.