Hi,
On 1/10/21 3:56 PM, Martin Sebor wrote:
Sure. I was confirming that based on the GCC dump there is no risk
of an overflow in the translation unit, and so there is no warning.
OK. :) I didn't understand the GCC dump. Despite having commit privs,
I'm not actually a compiler guru.
It can
On 1/10/21 12:28 PM, Bruce Korb wrote:
Hi Martin,
On 1/10/21 11:01 AM, Martin Sebor wrote:
On 1/8/21 12:38 PM, Bruce Korb via Gcc wrote:
This is the code that must be confusing to GCC. "def_str" points to
the second character in the 520 byte buffer. "def_scan" points to a
character that we al
Hi Martin,
On 1/10/21 11:01 AM, Martin Sebor wrote:
On 1/8/21 12:38 PM, Bruce Korb via Gcc wrote:
This is the code that must be confusing to GCC. "def_str" points to
the second character in the 520 byte buffer. "def_scan" points to a
character that we already know we're going to copy into the
On 1/8/21 12:38 PM, Bruce Korb via Gcc wrote:
$ bash cc.sh
+ wrn+=' -Werror=format-overflow'
+ gcc -DHAVE_CONFIG_H -I. -I.. -I../autoopts
-Wno-format-contains-nul -Wall -Werror -Wcast-align
-Wmissing-prototypes -Wpointer-arith -Wshadow -Wstrict-prototypes
-Wwrite-strings -
On 1/8/21 10:39 AM, Bruce Korb via Gcc wrote:
> Hi,
>
> You are supposed to be able to post once you've subscribed.
>
> Also, GCC's code analysis is wrong. "name_bf" contains *NO MORE* than
> MAXNAMELEN characters. That is provable.
>
> "def_str" points into a buffer of size ((MAXNAMELEN * 2) +
Hi,
You are supposed to be able to post once you've subscribed.
Also, GCC's code analysis is wrong. "name_bf" contains *NO MORE* than
MAXNAMELEN characters. That is provable.
"def_str" points into a buffer of size ((MAXNAMELEN * 2) + 8) and at an
offset maximum of MAXNAMELEN+1 (also provable
