From: "罗勇刚(Yonggang Luo)" <luoyonggang@gmail.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Kevin Wolf <kwolf@redhat.com>, Ed Maste <emaste@freebsd.org>,
Qemu-block <qemu-block@nongnu.org>, Stefan Weil <sw@weilnetz.de>,
Xie Changlong <xiechanglong.d@gmail.com>,
Peter Lieven <pl@kamp.de>,
QEMU Developers <qemu-devel@nongnu.org>,
Michael Roth <mdroth@linux.vnet.ibm.com>,
Gerd Hoffmann <kraxel@redhat.com>,
Wen Congyang <wencongyang2@huawei.com>,
Max Reitz <mreitz@redhat.com>, Li-Wen Hsu <lwhsu@freebsd.org>,
Markus Armbruster <armbru@redhat.com>
Subject: Re: [PULL 04/16] curses: Fixes curses compiling errors.
Date: Wed, 9 Sep 2020 05:04:19 +0800 [thread overview]
Message-ID: <CAE2XoE9rS4jBoQftniS19Xmj6LzDvAUJ-P5Oyu6ACTpOxogLfw@mail.gmail.com> (raw)
In-Reply-To: <CAFEAcA-FGVMKNObinzWgq6sYm9p0GCgPb3mXgx1LD5UnX0wZCQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3477 bytes --]
On Wed, Sep 9, 2020 at 4:29 AM Peter Maydell <peter.maydell@linaro.org>
wrote:
> On Tue, 8 Sep 2020 at 19:56, Yonggang Luo <luoyonggang@gmail.com> wrote:
> >
> > This is the compiling error:
> > ../ui/curses.c: In function 'curses_refresh':
> > ../ui/curses.c:256:5: error: 'next_maybe_keycode' may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
> > 256 | curses2foo(_curses2keycode, _curseskey2keycode, chr,
> maybe_keycode)
> > | ^~~~~~~~~~
> > ../ui/curses.c:302:32: note: 'next_maybe_keycode' was declared here
> > 302 | enum maybe_keycode next_maybe_keycode;
> > | ^~~~~~~~~~~~~~~~~~
> > ../ui/curses.c:256:5: error: 'maybe_keycode' may be used uninitialized
> in this function [-Werror=maybe-uninitialized]
> > 256 | curses2foo(_curses2keycode, _curseskey2keycode, chr,
> maybe_keycode)
> > | ^~~~~~~~~~
> > ../ui/curses.c:265:24: note: 'maybe_keycode' was declared here
> > 265 | enum maybe_keycode maybe_keycode;
> > | ^~~~~~~~~~~~~
> > cc1.exe: all warnings being treated as errors
>
> > Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
> > ---
> > ui/curses.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/ui/curses.c b/ui/curses.c
> > index 12bc682cf9..e4f9588c3e 100644
> > --- a/ui/curses.c
> > +++ b/ui/curses.c
> > @@ -262,7 +262,7 @@ static int curses2foo(const int _curses2foo[], const
> int _curseskey2foo[],
> > static void curses_refresh(DisplayChangeListener *dcl)
> > {
> > int chr, keysym, keycode, keycode_alt;
> > - enum maybe_keycode maybe_keycode;
> > + enum maybe_keycode maybe_keycode = CURSES_KEYCODE;
> >
> > curses_winch_check();
> >
> > @@ -299,7 +299,7 @@ static void curses_refresh(DisplayChangeListener
> *dcl)
> >
> > /* alt or esc key */
> > if (keycode == 1) {
> > - enum maybe_keycode next_maybe_keycode;
> > + enum maybe_keycode next_maybe_keycode = CURSES_KEYCODE;
> > int nextchr = console_getch(&next_maybe_keycode);
> >
> > if (nextchr != -1) {
>
> The problem here is that the compiler hasn't noticed that it's
> impossible to return something other than -1 from console_getch()
> without initializing next_maybe_keycode.
>
> There are two possible reasons for this:
> (1) your gcc is a bit old -- newer gcc are better at working
> out this kind of thing. But you said on irc that you're using
> gcc 10.2.0, which is new...
>
> (2) this is a variant of the problem with the system headers
> that causes us to have to redefine assert() in osdep.h, only
> with abort() (ie abort() is perhaps not marked as noreturn in
> the system headers). If this theory is true, then changing
> the abort() in console_getch() to instead be g_assert_not_reached()
> would be a different way to avoid the warnings (and if that works
> we should probably fix up abort() the way we do assert()).
>
Tried g_assert_not_reached still not fixes the issue, and I verified
on debug build, either g_assert_not_reached or abort, the compiling error
doesn't appear,
the debug build are the build that configured with --enable-debug-info
--enable-debug
this compiling error only appear in release build.
>
> thanks
> -- PMM
>
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
[-- Attachment #2: Type: text/html, Size: 4620 bytes --]
next prev parent reply other threads:[~2020-09-08 21:05 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-08 18:49 [PULL 00/16] Msys2 patches patches Yonggang Luo
2020-09-08 18:49 ` [PULL 01/16] block: Fixes nfs on msys2/mingw Yonggang Luo
2020-09-08 18:57 ` Eric Blake
2020-09-08 18:49 ` [PULL 02/16] ci: fixes msys2 build by upgrading capstone to 4.0.2 Yonggang Luo
2020-09-08 18:59 ` Eric Blake
2020-09-08 19:07 ` Philippe Mathieu-Daudé
2020-09-08 18:49 ` [PULL 03/16] configure: Fixes ncursesw detection under msys2/mingw and enable curses Yonggang Luo
2020-09-08 19:02 ` Eric Blake
2020-09-08 18:49 ` [PULL 04/16] curses: Fixes curses compiling errors Yonggang Luo
2020-09-08 20:28 ` Peter Maydell
2020-09-08 21:04 ` 罗勇刚(Yonggang Luo) [this message]
2020-09-08 18:49 ` [PULL 05/16] tests: disable /char/stdio/* tests in test-char.c on win32 Yonggang Luo
2020-09-08 18:49 ` [PULL 06/16] ci: Enable msys2 ci in cirrus Yonggang Luo
2020-09-08 18:49 ` [PULL 07/16] tests: Trying fixes test-replication.c on msys2/mingw Yonggang Luo
2020-09-08 18:49 ` [PULL 08/16] block: get file-win32.c handle locking option consistence with file-posix.c Yonggang Luo
2020-09-08 18:49 ` [PULL 09/16] osdep: These function are only available on Non-Win32 system Yonggang Luo
2020-09-08 18:49 ` [PULL 10/16] meson: Use -b to ignore CR vs. CR-LF issues on Windows Yonggang Luo
2020-09-08 18:49 ` [PULL 11/16] meson: disable crypto tests are empty under win32 Yonggang Luo
2020-09-08 18:49 ` [PULL 12/16] meson: remove empty else and duplicated gio deps Yonggang Luo
2020-09-08 18:49 ` [PULL 13/16] vmstate: Fixes test-vmstate.c on msys2/mingw Yonggang Luo
2020-09-08 18:49 ` [PULL 14/16] cirrus: Building freebsd in a single short Yonggang Luo
2020-09-08 18:49 ` [PULL 15/16] logging: Fixes memory leak in test-logging.c Yonggang Luo
2020-09-08 18:49 ` [PULL 16/16] rcu: add uninit destructor for rcu Yonggang Luo
2020-09-08 18:56 ` [PULL 00/16] Msys2 patches patches Eric Blake
2020-09-08 19:09 ` Philippe Mathieu-Daudé
2020-09-09 7:05 ` Thomas Huth
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=CAE2XoE9rS4jBoQftniS19Xmj6LzDvAUJ-P5Oyu6ACTpOxogLfw@mail.gmail.com \
--to=luoyonggang@gmail.com \
--cc=armbru@redhat.com \
--cc=emaste@freebsd.org \
--cc=kraxel@redhat.com \
--cc=kwolf@redhat.com \
--cc=lwhsu@freebsd.org \
--cc=mdroth@linux.vnet.ibm.com \
--cc=mreitz@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=pl@kamp.de \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=sw@weilnetz.de \
--cc=wencongyang2@huawei.com \
--cc=xiechanglong.d@gmail.com \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).