GNU bug report logs -
#57211
29.0.50; generate-new-buffer-name sprintf format overflow warning
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 57211 in the body.
You can then email your comments to 57211 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
eggert <at> cs.ucla.edu, bug-gnu-emacs <at> gnu.org
:
bug#57211
; Package
emacs
.
(Sun, 14 Aug 2022 16:51:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Basil L. Contovounesios" <contovob <at> tcd.ie>
:
New bug report received and forwarded. Copy sent to
eggert <at> cs.ucla.edu, bug-gnu-emacs <at> gnu.org
.
(Sun, 14 Aug 2022 16:51:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57211
; Package
emacs
.
(Sun, 14 Aug 2022 19:01:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 57211 <at> debbugs.gnu.org (full text, mbox):
"Basil L. Contovounesios" via "Bug reports for GNU Emacs, the Swiss army
knife of text editors" <bug-gnu-emacs <at> gnu.org> writes:
> 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?
I assume that gcc is concerned about the possibility that i may be
-999999 and the resulting string "--999999" which would overflow the
buffer.
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.
Personally, I'd change this code to use a buffer
INT_BUFSIZE_BOUND(int) + sizeof "-"
bytes large, like the just code below it. In other words, make it large
enough for type of i, and avoid delicate inferences made about the range
of values stored in i.
The "wasted" bytes in the buffer are minor in comparison to the human
effort required to verify this code for security correctness. :-)
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>
:
You have taken responsibility.
(Sun, 14 Aug 2022 20:55:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
"Basil L. Contovounesios" <contovob <at> tcd.ie>
:
bug acknowledged by developer.
(Sun, 14 Aug 2022 20:55:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 57211-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (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)]
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 12 Sep 2022 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 220 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.