[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c
From: |
Eli Zaretskii |
Subject: |
Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c |
Date: |
Tue, 27 Aug 2019 13:15:12 +0300 |
> Cc: address@hidden
> From: Paul Eggert <address@hidden>
> 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.
- Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c, (continued)
- Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c, Eli Zaretskii, 2019/08/26
- Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c, Paul Eggert, 2019/08/26
- Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c, Óscar Fuentes, 2019/08/26
- Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c, Eli Zaretskii, 2019/08/26
- Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c, Óscar Fuentes, 2019/08/26
- Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c, Paul Eggert, 2019/08/26
- Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c, Eli Zaretskii, 2019/08/27
- Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c, Paul Eggert, 2019/08/27
- Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c, Eli Zaretskii, 2019/08/27
- Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c, Paul Eggert, 2019/08/27
- Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c,
Eli Zaretskii <=
- Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c, Paul Eggert, 2019/08/27
- Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c, Eli Zaretskii, 2019/08/27
- Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c, Paul Eggert, 2019/08/26
- Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c, Eli Zaretskii, 2019/08/26
- Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c, Richard Stallman, 2019/08/26