bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paul Eggert
Subject: bug#57211: 29.0.50; generate-new-buffer-name sprintf format overflow warning
Date: Sun, 14 Aug 2022 13:54:08 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

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.

Attachment: 0001-Work-around-Bug-57211.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]