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

Previous Next

Package: emacs;

Reported by: "Basil L. Contovounesios" <contovob <at> tcd.ie>

Date: Sun, 14 Aug 2022 16:51:02 UTC

Severity: minor

Found in version 29.0.50

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

Bug is archived. No further changes may be made.

Full log


Message #13 received at 57211-done <at> debbugs.gnu.org (full text, mbox):

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

This bug report was last modified 2 years and 281 days ago.

Previous Next


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