* bug#51075: 29.0.50; Uninitialised variable warning in src/term.c
@ 2021-10-07 11:18 Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-10-07 13:01 ` Eli Zaretskii
0 siblings, 1 reply; 5+ messages in thread
From: Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-10-07 11:18 UTC (permalink / raw)
To: 51075; +Cc: Paul Eggert
Severity: minor
I'm currently seeing the following warning with GCC 10.3.0:
In file included from term.c:30:
term.c: In function ‘encode_terminal_code’:
lisp.h:1853:35: warning: ‘gstring’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1853 | return XVECTOR (array)->contents[idx];
| ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
term.c:553:16: note: ‘gstring’ was declared here
553 | Lisp_Object gstring;
| ^~~~~~~
I'm guessing it started with the following recent change:
Remove encode_terminal_code UNINITs
7e871dcd27 2021-10-03 17:52:28 -0700
https://git.sv.gnu.org/cgit/emacs.git/commit/?id=7e871dcd27
What's the best way to pacify it? Do we care about doing so in GCC 10?
Is
cmp = composition_table[src->u.cmp.id];
indeed guaranteed to be non-NULL? If so, maybe gstring could be
initialised as nil and then easserted as non-nil in the !cmp branch
(eassuming cmp is non-NULL in the !src->u.cmp.automatic branch does not
make the warning go away). If not, could there indeed be a bug?
Thanks,
--
Basil
In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
of 2021-10-07 built on tia
Repository revision: e338effc774f9a7cfe13d4a35dc1cf493a22c972
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux bookworm/sid
Configured using:
'configure 'CC=ccache gcc' 'CFLAGS=-Og -ggdb3' --config-cache --prefix
/home/blc/.local --enable-checking=structs --with-x-toolkit=lucid
--with-file-notification=yes --with-x'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XAW3D XDBE XIM XPM LUCID ZLIB
Important settings:
value of $LANG: en_IE.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
seq gv subr-x byte-opt bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo x-toolkit x multi-tty make-network-process emacs)
Memory information:
((conses 16 50810 6940)
(symbols 48 6621 1)
(strings 32 18974 1858)
(string-bytes 1 613497)
(vectors 16 13616)
(vector-slots 8 184446 10452)
(floats 8 23 47)
(intervals 56 231 0)
(buffers 992 10))
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#51075: 29.0.50; Uninitialised variable warning in src/term.c
2021-10-07 11:18 bug#51075: 29.0.50; Uninitialised variable warning in src/term.c Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-10-07 13:01 ` Eli Zaretskii
2021-10-07 20:13 ` Paul Eggert
2021-10-08 10:21 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 5+ messages in thread
From: Eli Zaretskii @ 2021-10-07 13:01 UTC (permalink / raw)
To: Basil L. Contovounesios; +Cc: 51075, eggert
> Cc: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 07 Oct 2021 12:18:14 +0100
> From: "Basil L. Contovounesios" via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>
> I'm currently seeing the following warning with GCC 10.3.0:
>
> In file included from term.c:30:
> term.c: In function ‘encode_terminal_code’:
> lisp.h:1853:35: warning: ‘gstring’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> 1853 | return XVECTOR (array)->contents[idx];
> | ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
> term.c:553:16: note: ‘gstring’ was declared here
> 553 | Lisp_Object gstring;
> | ^~~~~~~
It's a bogus warning. It might be worth reporting to the GCC folks
(unless GCC 11 already fixed that).
> Is
>
> cmp = composition_table[src->u.cmp.id];
>
> indeed guaranteed to be non-NULL?
If it's ever NULL, the very next line will segfault:
cmp = composition_table[src->u.cmp.id];
required = cmp->glyph_len;
> If so, maybe gstring could be
> initialised as nil and then easserted as non-nil in the !cmp branch
> (eassuming cmp is non-NULL in the !src->u.cmp.automatic branch does not
> make the warning go away). If not, could there indeed be a bug?
Feel free to assign some value to gstring in the 'else' clause, to
shut up GCC in this case.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#51075: 29.0.50; Uninitialised variable warning in src/term.c
2021-10-07 13:01 ` Eli Zaretskii
@ 2021-10-07 20:13 ` Paul Eggert
2021-10-08 10:21 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-10-08 10:21 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 5+ messages in thread
From: Paul Eggert @ 2021-10-07 20:13 UTC (permalink / raw)
To: Eli Zaretskii, Basil L. Contovounesios; +Cc: 51075-done
[-- Attachment #1: Type: text/plain, Size: 719 bytes --]
On 10/7/21 06:01, Eli Zaretskii wrote:
> It's a bogus warning. It might be worth reporting to the GCC folks
> (unless GCC 11 already fixed that).
Yes, I believed it's fixed in GCC 11. GCC 11.2.1 20210728 (Red Hat
11.2.1-1) does not warn me about it.
> Feel free to assign some value to gstring in the 'else' clause, to
> shut up GCC in this case.
I installed into the emacs-28 branch the attached, which fixes it in a
different way to make it a bit clearer to the reader that we're
pacifying an inadequate compiler rather than executing odd code for an
unknown reason.
There are a handful of other bogus warnings with GCC 11.2.1, which I'll
try to get around to pacifying (I hope before GCC 12 comes out :-).
[-- Attachment #2: 0001-Pacify-GCC-10.3-Wmaybe-uninitialized.patch --]
[-- Type: text/x-patch, Size: 781 bytes --]
From ac7bd3f3ec1d12ea255312778d5be674e5fbe293 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 7 Oct 2021 13:09:19 -0700
Subject: [PATCH] Pacify GCC 10.3 -Wmaybe-uninitialized
Problem reported by Basil L. Contovounesios (Bug#51075).
* src/term.c (encode_terminal_code):
Add an UNINIT to pacify GCC 10 bug.
---
src/term.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/term.c b/src/term.c
index 0858f81685..6f0b827cfc 100644
--- a/src/term.c
+++ b/src/term.c
@@ -550,7 +550,7 @@ encode_terminal_code (struct glyph *src, int src_len,
if (src->type == COMPOSITE_GLYPH)
{
struct composition *cmp;
- Lisp_Object gstring;
+ Lisp_Object gstring UNINIT;
int i;
nbytes = buf - encode_terminal_src;
--
2.31.1
^ permalink raw reply related [flat|nested] 5+ messages in thread
* bug#51075: 29.0.50; Uninitialised variable warning in src/term.c
2021-10-07 13:01 ` Eli Zaretskii
2021-10-07 20:13 ` Paul Eggert
@ 2021-10-08 10:21 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 0 replies; 5+ messages in thread
From: Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-10-08 10:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 51075, eggert
Eli Zaretskii [2021-10-07 09:02 -0400] wrote:
>> Cc: Paul Eggert <eggert@cs.ucla.edu>
>> Date: Thu, 07 Oct 2021 12:18:14 +0100
>> From: "Basil L. Contovounesios" via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>
>> Is
>>
>> cmp = composition_table[src->u.cmp.id];
>>
>> indeed guaranteed to be non-NULL?
>
> If it's ever NULL, the very next line will segfault:
>
> cmp = composition_table[src->u.cmp.id];
> required = cmp->glyph_len;
Right, I didn't read carefully enough.
Thanks,
--
Basil
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#51075: 29.0.50; Uninitialised variable warning in src/term.c
2021-10-07 20:13 ` Paul Eggert
@ 2021-10-08 10:21 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 5+ messages in thread
From: Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-10-08 10:21 UTC (permalink / raw)
To: Paul Eggert; +Cc: 51075, Eli Zaretskii
Paul Eggert [2021-10-07 13:13 -0700] wrote:
> On 10/7/21 06:01, Eli Zaretskii wrote:
>
>> It's a bogus warning. It might be worth reporting to the GCC folks
>> (unless GCC 11 already fixed that).
>
> Yes, I believed it's fixed in GCC 11. GCC 11.2.1 20210728 (Red Hat 11.2.1-1)
> does not warn me about it.
>
>> Feel free to assign some value to gstring in the 'else' clause, to
>> shut up GCC in this case.
>
> I installed into the emacs-28 branch the attached, which fixes it in a different
> way to make it a bit clearer to the reader that we're pacifying an inadequate
> compiler rather than executing odd code for an unknown reason.
>
> There are a handful of other bogus warnings with GCC 11.2.1, which I'll try to
> get around to pacifying (I hope before GCC 12 comes out :-).
Thanks!
--
Basil
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-10-08 10:21 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-10-07 11:18 bug#51075: 29.0.50; Uninitialised variable warning in src/term.c Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-10-07 13:01 ` Eli Zaretskii
2021-10-07 20:13 ` Paul Eggert
2021-10-08 10:21 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-10-08 10:21 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).