emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#51075: closed (29.0.50; Uninitialised variable warning in src/term.c


From: GNU bug Tracking System
Subject: bug#51075: closed (29.0.50; Uninitialised variable warning in src/term.c)
Date: Thu, 07 Oct 2021 20:14:02 +0000

Your message dated Thu, 7 Oct 2021 13:13:33 -0700
with message-id <421a1f09-6b02-0e36-3763-010a21b3f39c@cs.ucla.edu>
and subject line Re: bug#51075: 29.0.50; Uninitialised variable warning in 
src/term.c
has caused the debbugs.gnu.org bug report #51075,
regarding 29.0.50; Uninitialised variable warning in src/term.c
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
51075: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=51075
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: 29.0.50; Uninitialised variable warning in src/term.c Date: Thu, 07 Oct 2021 12:18:14 +0100
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))



--- End Message ---
--- Begin Message --- Subject: Re: bug#51075: 29.0.50; Uninitialised variable warning in src/term.c Date: Thu, 7 Oct 2021 13:13:33 -0700 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0
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: 0001-Pacify-GCC-10.3-Wmaybe-uninitialized.patch
Description: Text Data


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]