Compile warning -Wmaybe-uninitialized in ex_cmds.c after applying patches 9.1.1474 to 1478

[Tony Mechelynck]

Compile warning -Wmaybe-uninitialized in ex_cmds.c after applying
patches 9.1.1474 to 1478
On "make reconfig" in any build using gcc (SUSE Linux) 15.1.1 20250528:

ex_cmds.c: In function ‘ex_uniq’:
ex_cmds.c:838:24: warning: ‘save_c’ may be used uninitialized
[-Wmaybe-uninitialized]
838 | s[end_col] = save_c;
| ~~~~~~~~~~~^~~~~~~~
ex_cmds.c:659:17: note: ‘save_c’ was declared here
659 | char_u save_c; // temporary character storage
| ^~~~~~

False alarm ?

Best regards,
Tony.

[Christian Brabandt]

That looks like a false alarm. But I'll initialize it anyhow.

Thanks Tony for reporting,
Christian
--
You can't mend a wristwatch while falling from an airplane.

[Tony Mechelynck]

After applying patches 1539 and 1540 I get the following in all builds
(Tiny, Normal and Huge):

insexpand.c: In function ‘ins_compl_new_leader’:
insexpand.c:2459:9: warning: ‘save_w_wrow’ may be used uninitialized
[-Wmaybe-uninitialized]
2459 | show_pum(save_w_wrow, save_w_leftcol);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
insexpand.c:2398:13: note: ‘save_w_wrow’ was declared here
2398 | int save_w_wrow;
| ^~~~~~~~~~~
insexpand.c:2459:9: warning: ‘save_w_leftcol’ may be used
uninitialized [-Wmaybe-uninitialized]
2459 | show_pum(save_w_wrow, save_w_leftcol);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
insexpand.c:2399:13: note: ‘save_w_leftcol’ was declared here
2399 | int save_w_leftcol;
| ^~~~~~~~~~~~~~

Link proceeds normally.

This is with gcc 15.1.1 on openSUSE Tumbleweed.

Best regards,
Tony.

[Christian Brabandt]

On Mo, 14 Jul 2025, Tony Mechelynck wrote:

> After applying patches 1539 and 1540 I get the following in all builds
> (Tiny, Normal and Huge):
>
> insexpand.c: In function ‘ins_compl_new_leader’:
> insexpand.c:2459:9: warning: ‘save_w_wrow’ may be used uninitialized
> [-Wmaybe-uninitialized]
> 2459 | show_pum(save_w_wrow, save_w_leftcol);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> insexpand.c:2398:13: note: ‘save_w_wrow’ was declared here
> 2398 | int save_w_wrow;
> | ^~~~~~~~~~~
> insexpand.c:2459:9: warning: ‘save_w_leftcol’ may be used
> uninitialized [-Wmaybe-uninitialized]
> 2459 | show_pum(save_w_wrow, save_w_leftcol);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> insexpand.c:2399:13: note: ‘save_w_leftcol’ was declared here
> 2399 | int save_w_leftcol;
> | ^~~~~~~~~~~~~~

Faster than Coverity ;)

> Link proceeds normally.
>
> This is with gcc 15.1.1 on openSUSE Tumbleweed.

Thanks, should be fixed now with v9.1.1542

Christian
--
Maryann's Law:
You can always find what you're not looking for.

[Tony Mechelynck]

Are you sure you pushed it to https://www.vim.org/hgweb/vim/ ? "hg in"
gives me nothing new after the runtime files changeset which followed
patch 1540 yesterday.

N.B. I am getting sporadically "HTTP error 503: Service unavailable",
often but not every time, and when I don't there are "no changes
found".

Best regards,
Tony.

>
> Christian
> --
> Maryann's Law:
> You can always find what you're not looking for.
>

> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/vim_dev/aHVfGMMuiJa5gKyt%40256bit.org.

[Christian Brabandt]

On Mo, 14 Jul 2025, Tony Mechelynck wrote:

> Are you sure you pushed it to https://www.vim.org/hgweb/vim/ ? "hg in"
> gives me nothing new after the runtime files changeset which followed
> patch 1540 yesterday.

I did now trigger it manually.

> N.B. I am getting sporadically "HTTP error 503: Service unavailable",
> often but not every time, and when I don't there are "no changes
> found".

It might be time to consider migrating to git.

Thanks,
Christian
--
Iles's Law:
There is always an easier way to do it. When looking directly
at the easy way, especially for long periods, you will not see it.
Neither will Iles.

[Tony Mechelynck]

On Tue, Jul 15, 2025 at 8:13 AM Christian Brabandt <cbl...@256bit.org> wrote:
>
>
> On Mo, 14 Jul 2025, Tony Mechelynck wrote:
>
> > Are you sure you pushed it to https://www.vim.org/hgweb/vim/ ? "hg in"
> > gives me nothing new after the runtime files changeset which followed
> > patch 1540 yesterday.
>
> I did now trigger it manually.

Thanks.

>
> > N.B. I am getting sporadically "HTTP error 503: Service unavailable",
> > often but not every time, and when I don't there are "no changes
> > found".
>
> It might be time to consider migrating to git.

I hate git, if I try I expect to be constantly doing the opposite of
what I mean to do. Am I really the only one still getting the Vim
source from the Mercurial server ?

>
> Thanks,
> Christian
> --
> Iles's Law:
> There is always an easier way to do it. When looking directly
> at the easy way, especially for long periods, you will not see it.
> Neither will Iles.

Best regards,
Tony.

[Christian Brabandt]

On Di, 15 Jul 2025, Tony Mechelynck wrote:

> I hate git, if I try I expect to be constantly doing the opposite of
> what I mean to do. Am I really the only one still getting the Vim
> source from the Mercurial server ?

It's not so bad, especially if you are only want to keep in sync with
latest development. If you are just following development process
without making any changes like (documentation or translation changes),
it's just basically a "git reset --hard" (to throw away all local
changes) followed by "git pull --ff"

Plus, nowadays you get much better help on git than on hg.

Thanks,
Christian
--
** MAXIMUM TERMINALS ACTIVE. TRY AGAIN LATER **

[Marvin Renich]

* Tony Mechelynck <antoine.m...@gmail.com> [250715 07:36]:

> On Tue, Jul 15, 2025 at 8:13 AM Christian Brabandt <cbl...@256bit.org> wrote:
> > > N.B. I am getting sporadically "HTTP error 503: Service unavailable",
> > > often but not every time, and when I don't there are "no changes
> > > found".
> >
> > It might be time to consider migrating to git.
>
> I hate git, if I try I expect to be constantly doing the opposite of
> what I mean to do. Am I really the only one still getting the Vim
> source from the Mercurial server ?

I know I have suggested this before, but you can use the hggit extension
(Debian package mercurial-git). Enable it in ~/.hgrc as

[extensions]
hggit =

You can then clone a git repo as a local mercurial repo with, e.g.,

hg clone git+https://github.com/vim/vim.git

For large repos like vim, there are really only two downsides to this:
it takes a while to convert the git repo to mercurial during the initial
clone, and it take twice as much disk space because hggit needs a local
copy of the git repo in addition to the hg repo.

These are both relatively mild annoyances compared to the benefit of
being able to use mercurial to manage the repo locally. The vim git
repo is only about 250M, which really isn't that much.

...Marvin

[Tony Mechelynck]

After updating the source from 9.1.1646 to 9.1.1652:

gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MOTIF -O2
-fno-strength-reduce -Wall -Wno-deprecated-declarations -D_REENTRANT
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -o
objects/wlr-data-control-unstable-v1.o auto/wayland/wlr-data-control-
unstable-v1.c
auto/wayland/wlr-data-control-unstable-v1.c:32:10: fatal error:
wayland-util.h: No such file or directory
32 | #include "wayland-util.h"
| ^~~~~~~~~~~~~~~~
compilation terminated.
make[1]: *** [Makefile:3664: objects/wlr-data-control-unstable-v1.o] Error 1
make[1]: Leaving directory '/root/.build/vim/vim-hg/src/shadow-normal'
make: *** [Makefile:2035: reconfig] Error 2
exit status 2

Does not happen in Huge build with GTK3 GUI
Happens in Normal build with Motif GUI
Does not happen in Tiny build with Motif GUI
Does not happen in Tiny build with no GUI.

Happens in Normal even after regenerating the Normal shadow-directory
then replacing its Makefile by a symlink to ../Makefile and adding a
bash script to set the desired configure options in the environment
(before regenerating I saved the existing script, as follows:

#!/bin/bash
export CONF_OPT_GUI='--enable-gui=motif'
export CONF_OPT_MULTIBYTE='--enable-multibyte'
export CONF_OPT_AUTOSERVE='--enable-autoservername'
export CONF_OPT_SODIUM='--enable-libsodium'
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"'

The above is to be "source"d not "execute"d.

After some looking around, I find that:
— Huge build (GOOD) has compilation flag -I/usr/include/wayland and
link flag -lwayland-client, builds successfully with +wayland
+wayland_clipboard +X11
— Normal build (BAD) has link flag -lwayland-client but lacks
compilation flag -I/usr/include/wayland, does not build
— Tiny with Motif (GOOD) has neither flag, builds successfully with
-wayland -wayland_clipboard +X11
— Tiny without GUI (GOOD) has neither flag, builds successfully with
-wayland -wayland_clipboard -X11

Is it possible to build without Wayland even if the Wayland packages
are installed (configure flag --without-wayland or --disable-wayland
or something)? I see nothing in the src/Makefile, neither in the
comments nor in the code.

Best regards,
Tony.

[Christian Brabandt]

The configure script supports --without-wayland.

Thanks,
Christian
--
Elbonics, n.:
The actions of two people maneuvering for one armrest in a movie
theatre.
-- "Sniglets", Rich Hall & Friends

[Tony Mechelynck]

Ah, thanks. With
export CONF_OPT_X='--without-wayland'
added to the environment (the rest unchanged) then "make reconfig" it
builds successfully again. (I'm not sure it is the exact correct
environment variable but it works). I noticed a totally unrelated
warning in another module but I'll report it separately on the
principle of "one bug, one report".
>
> Thanks,
> Christian

Best regards,
Tony.

[Tony Mechelynck]

At patchlevel 9.1.1652:

gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MOTIF -O2
-fno-strength-reduce -Wall -Wno-deprecated-declarations -D_REENTRANT

-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -o objects/clientserver.o
clientserver.c
In function ‘cmdsrv_main’,
inlined from ‘exec_on_server’ at clientserver.c:233:2:
clientserver.c:458:16: warning: ‘ret’ may be used uninitialized
[-Wmaybe-uninitialized]
458 | if (ret < 0)
| ^
clientserver.c: In function ‘exec_on_server’:
clientserver.c:333:17: note: ‘ret’ was declared here
333 | int ret;
| ^~~

The configuration for this build is as follows:
#!/bin/bash
export CONF_OPT_GUI='--enable-gui=motif'
export CONF_OPT_X='--without-wayland'

export CONF_OPT_MULTIBYTE='--enable-multibyte'
export CONF_OPT_AUTOSERVE='--enable-autoservername'
export CONF_OPT_SODIUM='--enable-libsodium'
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"'

I haven't checked whether or not the same warning occurs in Huge and
Tiny builds.

Best regards,
Tony.

[Christian Brabandt]

Thanks, that should be fixed by v9.1.1661.

Thanks,
Christian
--
Regression analysis:
Mathematical techniques for trying to understand why things are
getting worse.

[Christian Brabandt]

I think this particular issue might have been fixed by v9.1.1658. I
hope, not quite sure.

Thanks,
Christian
--
"It's men like him that give the Y chromosome a bad name."

[Tony Mechelynck]

After seeing the recent new changesets (but before seeing this mail) I tried
CONF_OPT_X= make reconfig
in my "shell to build Normal Vim", i.e. temporarily removing the
configure parameter --without-wayland, and it worked indeed. A Normal
build with +wayland +wayland_clipboard was produced. So I'm going to
comment out that line in my "normal" configuration and make sure that
$CONF_OPT_X is unset.

Thanks!
Tony.

[Tony Mechelynck]

Yes, I applied patches 9.1.1661 and 9.1.1662 together and thereafter I
don't see any warnings, not even in clientserver.c

Best regards,
Tony.

[Tony Mechelynck]

Trying to run "hg in || echo 'exit status' $?" on https://www.vim.org/hgweb/vim/
gives
abort: HTTP Error 503: Service Unavailable
exit status 255

I suppose it will go away after a few hours but maybe better report it anyway.

Best regards,
Tony.