GNU bug report logs - #57211
29.0.50; generate-new-buffer-name sprintf format overflow warning

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Subject: bug#57211: closed (Re: bug#57211: 29.0.50; generate-new-buffer-name
 sprintf format overflow warning)
Date: Sun, 14 Aug 2022 20:55:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#57211: 29.0.50; generate-new-buffer-name sprintf format overflow warning

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 57211 <at> debbugs.gnu.org.

-- 
57211: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57211
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: 57211-done <at> debbugs.gnu.org
Subject: Re: bug#57211: 29.0.50; generate-new-buffer-name sprintf format
 overflow warning
Date: Sun, 14 Aug 2022 13:54:08 -0700

[Message part 3 (text/plain, inline)]

On 8/14/22 09:50, Basil L. Contovounesios wrote:

> Can the upper bound 9 ever be achieved?  If so, how?  If not, is this a
> GCC bug?  Either way, is there a way to pacify the warning?

It can't be achieved, and it's arguably a GCC bug. I installed the 
attached to pacify GCC.

>    int i = r % 1000000;
> 
> can the result of % ever exceed INT_MAX?

No.


On 8/14/22 11:59, Matt Armstrong wrote:

> Gcc doesn't know that get_random() returns only non-negative numbers,
> and the eassume() call doesn't seem to be enough to convince gcc this
> fact, or gcc does not infer i is also non-negative.

It's worse than that. Even if you add 'eassume (0 <= i && i < 1000000);" 
GCC still doesn't assume that the sprintf is in range.

> Personally, I'd change this code to use a buffer
> 
>    INT_BUFSIZE_BOUND(int) + sizeof "-"

The problem with overallocating buffers is not the memory loss (it's 
trivial, as you say), it's that later readers like me will wonder why 
the buffer is being overallocated, which is maintenance overhead.

I installed the attached to pacify GCC while also attempting to not 
entirely mystify later readers.

[0001-Work-around-Bug-57211.patch (text/x-patch, attachment)]

[Message part 5 (message/rfc822, inline)]

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; generate-new-buffer-name sprintf format overflow warning
Date: Sun, 14 Aug 2022 19:50:03 +0300

Severity: minor

Compiling with gcc (Debian 12.1.0-7) 12.1.0 and -Og, I get the following
-Wformat-overflow warning:

In file included from buffer.c:33:
buffer.c: In function ‘Fgenerate_new_buffer_name’:
buffer.c:1167:46: warning: ‘sprintf’ may write a terminating nul past the end of the destination [-Wformat-overflow=]
 1167 |       AUTO_STRING_WITH_LEN (lnumber, number, sprintf (number, "-%d", i));
      |                                              ^~~~~~~~~~~~~~~~~~~~~~~~~~
lisp.h:5493:36: note: in definition of macro ‘AUTO_STRING_WITH_LEN’
 5493 |         ((&(struct Lisp_String) {{{len, -1, 0, (unsigned char *) (str)}}}), \
      |                                    ^~~
buffer.c:1167:46: note: ‘sprintf’ output between 3 and 9 bytes into a destination of size 8
 1167 |       AUTO_STRING_WITH_LEN (lnumber, number, sprintf (number, "-%d", i));
      |                                              ^~~~~~~~~~~~~~~~~~~~~~~~~~
lisp.h:5493:36: note: in definition of macro ‘AUTO_STRING_WITH_LEN’
 5493 |         ((&(struct Lisp_String) {{{len, -1, 0, (unsigned char *) (str)}}}), \
      |                                    ^~~

Can the upper bound 9 ever be achieved?  If so, how?  If not, is this a
GCC bug?  Either way, is there a way to pacify the warning?

I tried

  snprintf (number, sizeof number, ...)

but got the same warning.

BTW, in the preceding

  int i = r % 1000000;

can the result of % ever exceed INT_MAX?  And do we care either way?

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 2022-08-14 built on tia
Repository revision: 1d3fe256907d5e78a4acedd194e55db8ab952952
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Debian GNU/Linux bookworm/sid

Configured using:
 'configure CC=gcc-12 'CFLAGS=-Og -ggdb3' --config-cache
 --prefix=/home/blc/.local --enable-checking=structs
 --with-file-notification=yes --with-x-toolkit=lucid --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 SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS WEBP X11 XAW3D XDBE XIM XINPUT2 XPM LUCID ZLIB

Important settings:
  value of $LANG: en_IE.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.