GNU bug report logs -
#75967
Pacify stringop truncation GCC warning
Previous Next
To reply to this bug, email your comments to 75967 AT debbugs.gnu.org.
There is no need to reopen the bug first.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#75967
; Package
emacs
.
(Fri, 31 Jan 2025 11:30:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Pip Cet <pipcet <at> protonmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 31 Jan 2025 11:30:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Every once in a while, compilers start complaining about
static const char hexchar[16] = "0123456789ABCDEF";
because they think what was meant was
static const char hexchar[17] = "0123456789ABCDEF";
This leads to endless arguments; usually, the warning (or error) is
disabled again for a while, and then reintroduced again shortly
thereafter. Compiling with current GCC 15 appears to indicate we're
back to the compiler warning about this code, and aborting the build
because of it if configured with --enable-gcc-warnings
At this point, I think it's a waste of time to go over the argument
again. Let's omit the explicit array size in our code, accepting the
unnecessary NUL byte for now?
Okay for master?
From a047708839bd8b75e6b533158083671740ba0ef7 Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet <at> protonmail.com>
Subject: [PATCH] Pacify GCC warnings by wasting some static memory (bug#TBD)
* src/fns.c (hexbuf_digest):
* src/json.c (json_out_string): Omit array bounds on array of hex
characters.
---
src/fns.c | 2 +-
src/json.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/fns.c b/src/fns.c
index 081ed2b9f51..9b21a69d0db 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -6095,7 +6095,7 @@ hexbuf_digest (char *hexbuf, void const *digest, int digest_size)
for (int i = digest_size - 1; i >= 0; i--)
{
- static char const hexdigit[16] = "0123456789abcdef";
+ static char const hexdigit[] = "0123456789abcdef";
int p_i = p[i];
hexbuf[2 * i] = hexdigit[p_i >> 4];
hexbuf[2 * i + 1] = hexdigit[p_i & 0xf];
diff --git a/src/json.c b/src/json.c
index 4e156658ef7..deb0a2ec594 100644
--- a/src/json.c
+++ b/src/json.c
@@ -323,7 +323,7 @@ json_out_string (json_out_t *jo, Lisp_Object str, int skip)
{
/* FIXME: this code is slow, make faster! */
- static const char hexchar[16] = "0123456789ABCDEF";
+ static const char hexchar[] = "0123456789ABCDEF";
ptrdiff_t len = SBYTES (str);
json_make_room (jo, len + 2);
json_out_byte (jo, '"');
--
2.48.1
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#75967
; Package
emacs
.
(Sat, 01 Feb 2025 09:41:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 75967 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 31 Jan 2025 11:29:29 +0000
> From: Pip Cet via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> Every once in a while, compilers start complaining about
>
> static const char hexchar[16] = "0123456789ABCDEF";
>
> because they think what was meant was
>
> static const char hexchar[17] = "0123456789ABCDEF";
>
> This leads to endless arguments; usually, the warning (or error) is
> disabled again for a while, and then reintroduced again shortly
> thereafter. Compiling with current GCC 15 appears to indicate we're
> back to the compiler warning about this code, and aborting the build
> because of it if configured with --enable-gcc-warnings
>
> At this point, I think it's a waste of time to go over the argument
> again. Let's omit the explicit array size in our code, accepting the
> unnecessary NUL byte for now?
>
> Okay for master?
Given the subsequent discussions in bug#75964, should we now close
this bug?
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>
:
You have taken responsibility.
(Sat, 01 Feb 2025 18:31:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Pip Cet <pipcet <at> protonmail.com>
:
bug acknowledged by developer.
(Sat, 01 Feb 2025 18:31:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 75967-done <at> debbugs.gnu.org (full text, mbox):
On 2025-02-01 01:40, Eli Zaretskii wrote:
> Given the subsequent discussions in bug#75964, should we now close
> this bug?
Yes, let's leave that code alone for now. The obvious workaround would
mean that an Emacs built with low-level C runtime checking wouldn't
catch the error in "hexchar[16]".
We can wait for GCC 15 to become final before deciding whether to attack
the false positive via GCC 15's nonstring features (if they're working)
or via a pragma or some other mechanism (if not).
The general idea here is that for --enable-gcc-warnings we should focus
on the latest stable GCC version. If it's any real trouble to work
around a false positive in the planned next version of GCC then we
shouldn't bother with the workaround. In that sense, future versions of
GCC should be treated like past versions.
Closing.
This bug report was last modified 6 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.