GNU bug report logs - #75967
Pacify stringop truncation GCC warning

Previous Next

Package: emacs;

Reported by: Pip Cet <pipcet <at> protonmail.com>

Date: Fri, 31 Jan 2025 11:30:03 UTC

Severity: normal

Done: Paul Eggert <eggert <at> cs.ucla.edu>

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.

View this report as an mbox folder, status mbox, maintainer mbox


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):

From: Pip Cet <pipcet <at> protonmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Pacify stringop truncation GCC warning
Date: Fri, 31 Jan 2025 11:29:29 +0000
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):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 75967 <at> debbugs.gnu.org
Subject: Re: bug#75967: Pacify stringop truncation GCC warning
Date: Sat, 01 Feb 2025 11:40:32 +0200
> 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):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, Pip Cet <pipcet <at> protonmail.com>
Cc: 75967-done <at> debbugs.gnu.org
Subject: Re: bug#75967: Pacify stringop truncation GCC warning
Date: Sat, 1 Feb 2025 10:30:04 -0800
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.