Compilation warnings in builds with expression evaluation

[Tony Mechelynck]

I noticed this in a "make reconfig" at patchlevel 9.0.1429. It may or
may not have happened earlier. Builds without expression evaluation
are not affected.

The following is from a Normal build without the -j argument to make,
to avoid line-interlacing from builds of different modules:

gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-I/usr/include/gtk-3.0 -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/harfbuzz -I/usr/include/freetype2
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi
-I/usr/include/cairo -I/usr/include/libpng16 -I/usr/include/pixman-1
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0
-I/usr/include/wayland -I/usr/include/libxkbcommon
-I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0
-I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0
-I/usr/lib64/dbus-1.0/include -pthread -O2 -fno-strength-reduce
-Wall -Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1 -o objects/memline.o memline.c
memline.c: In function ‘adjust_text_props_for_delete’:
memline.c:3623:43: warning: ‘this_props_len’ may be used uninitialized
[-Wmaybe-uninitialized]
3623 | for (done_this = 0; done_this < this_props_len;
| ~~~~~~~~~~^~~~~~~~~~~~~~~~
memline.c:3582:17: note: ‘this_props_len’ was declared here
3582 | int this_props_len;
| ^~~~~~~~~~~~~~
In file included from vim.h:244,
from memline.c:45:
memline.c:3630:56: warning: ‘text’ may be used uninitialized
[-Wmaybe-uninitialized]
3630 | mch_memmove(&prop_this, text + textlen + done_this,
os_unix.h:430:68: note: in definition of macro ‘mch_memmove’
430 | # define mch_memmove(to, from, len) memmove((char *)(to),
(char *)(from), len)
| ^~~~
memline.c:3583:18: note: ‘text’ was declared here
3583 | char_u *text;
| ^~~~
memline.c:3630:56: warning: ‘textlen’ may be used uninitialized
[-Wmaybe-uninitialized]
3630 | mch_memmove(&prop_this, text + textlen + done_this,
| ^
os_unix.h:430:68: note: in definition of macro ‘mch_memmove’
430 | # define mch_memmove(to, from, len) memmove((char *)(to),
(char *)(from), len)
| ^~~~
memline.c:3584:17: note: ‘textlen’ was declared here
3584 | size_t textlen;
| ^~~~~~~

The configuration arguments for this build are set as follows:

export CONF_OPT_GUI='--enable-gui=gtk3'
export CONF_OPT_MULTIBYTE='--enable-multibyte'
export CONF_OPT_AUTOSERVE='--enable-autoservername'
export CONF_OPT_FEAT='--with-features=normal'
export CONF_ARGS2='--with-vim-name=vim-normal'
export CONF_OPT_COMPBY='"--with-compiledby=antoine.m...@gmail.com"'


Best regards,
Tony.

[Bram Moolenaar]

Tony wrote:

> I noticed this in a "make reconfig" at patchlevel 9.0.1429. It may or
> may not have happened earlier. Builds without expression evaluation
> are not affected.
>
> The following is from a Normal build without the -j argument to make,
> to avoid line-interlacing from builds of different modules:
>
> gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
> -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0
> -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
> -I/usr/include/harfbuzz -I/usr/include/freetype2
> -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi
> -I/usr/include/cairo -I/usr/include/libpng16 -I/usr/include/pixman-1
> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0
> -I/usr/include/wayland -I/usr/include/libxkbcommon
> -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0
> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0
> -I/usr/lib64/dbus-1.0/include -pthread -O2 -fno-strength-reduce
> -Wall -Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
> -D_FORTIFY_SOURCE=1 -o objects/memline.o memline.c
> memline.c: In function ‘adjust_text_props_for_delete’:
> memline.c:3623:43: warning: ‘this_props_len’ may be used uninitialized
> [-Wmaybe-uninitialized]
> 3623 | for (done_this = 0; done_this < this_props_len;
> | ~~~~~~~~~~^~~~~~~~~~~~~~~~

I cannot make this warning show up. I did add the "-O2" argument to
gcc, that usually reveals these "may be used uninitialized" warnings.
I assume you use a different version of gcc. I'm afraid I cannot guess
what would be the best way to get rid of these warnings. It looks like
the optimizer doesn't see that "did_get_line" is FALSE at first and the
block that sets the variables will always be executed before they are
used.

Can someone reproduce the warning and come up with a reasonable solution?
I don't think initializing the variables is a good solution, that should
not be necessary.

--
CUSTOMER: Well, can you hang around a couple of minutes? He won't be
long.
MORTICIAN: Naaah, I got to go on to Robinson's -- they've lost nine today.
CUSTOMER: Well, when is your next round?
MORTICIAN: Thursday.
DEAD PERSON: I think I'll go for a walk.
The Quest for the Holy Grail (Monty Python)

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Tony Mechelynck]

At this moment, my gcc version is 13-1.2-x86_64 and my OS is openSUSE
Tumbleweed, snapshot 20230326. Also installed are, among others,
gcc13, cpp13 and libstdc++6-devel-gcc13, all at version
13.0.1+git6669-1.1-x86_64.

The answer to "gcc --version" is
gcc (SUSE Linux) 13.0.1 20230314 (experimental) [revision
42630fadbe248717859d61c0244c821c32b4e52c]
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

>
> Can someone reproduce the warning and come up with a reasonable solution?
> I don't think initializing the variables is a good solution, that should
> not be necessary.

As long as warning messages don't prevent production of an executable
program, and as long as that executable does what I expect of it in
terms of editing properly and not crashing, I can live with them; but
I know that you prefer not having the compiler's output cluttered with
useless warnings. I suppose that changing the Makefile to compile all
modules with -Wno-maybe-uninitialized is not an option because when
this message appears it should usually be looked into.

Best regards,
Tony.

[Bram Moolenaar]

Tony wrote:

> > > I noticed this in a "make reconfig" at patchlevel 9.0.1429. It may or
> > > may not have happened earlier. Builds without expression evaluation
> > > are not affected.
> > >
> > > The following is from a Normal build without the -j argument to make,
> > > to avoid line-interlacing from builds of different modules:
> > >
> > > gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
> > > -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0
> > > -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
> > > -I/usr/include/harfbuzz -I/usr/include/freetype2
> > > -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi
> > > -I/usr/include/cairo -I/usr/include/libpng16 -I/usr/include/pixman-1
> > > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0
> > > -I/usr/include/wayland -I/usr/include/libxkbcommon
> > > -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0
> > > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0
> > > -I/usr/lib64/dbus-1.0/include -pthread -O2 -fno-strength-reduce
> > > -Wall -Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE

> > > -D_FORTIFY_SOURCE=3D1 -o objects/memline.o memline.c
> > > memline.c: In function =E2=80=98adjust_text_props_for_delete=E2=80=99:
> > > memline.c:3623:43: warning: =E2=80=98this_props_len=E2=80=99 may be use=
> d uninitialized
> > > [-Wmaybe-uninitialized]
> > > 3623 | for (done_this =3D 0; done_this < this_props_len;

> > > | ~~~~~~~~~~^~~~~~~~~~~~~~~~
> >
> > I cannot make this warning show up. I did add the "-O2" argument to
> > gcc, that usually reveals these "may be used uninitialized" warnings.
> > I assume you use a different version of gcc. I'm afraid I cannot guess
> > what would be the best way to get rid of these warnings. It looks like
> > the optimizer doesn't see that "did_get_line" is FALSE at first and the
> > block that sets the variables will always be executed before they are
> > used.
>
> At this moment, my gcc version is 13-1.2-x86_64 and my OS is openSUSE
> Tumbleweed, snapshot 20230326. Also installed are, among others,
> gcc13, cpp13 and libstdc++6-devel-gcc13, all at version
> 13.0.1+git6669-1.1-x86_64.

I'm on Ubuntu, which is using gcc 12.2.0. It might be a gcc 13 problem.

> > Can someone reproduce the warning and come up with a reasonable solution?
> > I don't think initializing the variables is a good solution, that should
> > not be necessary.
>
> As long as warning messages don't prevent production of an executable
> program, and as long as that executable does what I expect of it in
> terms of editing properly and not crashing, I can live with them; but
> I know that you prefer not having the compiler's output cluttered with
> useless warnings. I suppose that changing the Makefile to compile all
> modules with -Wno-maybe-uninitialized is not an option because when
> this message appears it should usually be looked into.

The message may be a valid warning. But in this case it's just
confusing and might valid warnings go unnoticed. Thus I try to avoid
them.

--
`When any government, or any church for that matter, undertakes to say to
its subjects, "This you may not read, this you must not see, this you are
forbidden to know," the end result is tyranny and oppression no matter how
holy the motives' -- Robert A Heinlein, "If this goes on --"