https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101997
Richard Biener changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101997
--- Comment #4 from anlauf at gcc dot gnu.org ---
I have run the testcase under the debugger and the longest arguments to
sprintf I have found is
"m2345678901234567890123456789012345678901234567890123456789_123.n234567890123456789012345678901234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101997
--- Comment #3 from anlauf at gcc dot gnu.org ---
Created attachment 51348
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51348&action=edit
Partial backport of commit ac932bfcd21e9523fa2b880ae8138aef79da7f54
It's not that the cherry-pick w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101997
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101997
--- Comment #1 from anlauf at gcc dot gnu.org ---
Can you get more details on where the buffer overflow actually occurs?
I cannot reproduce it on x86_64-pc-linux-gnu even running f951 under valgrind.
The original testcase in pr95091 would have I