https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87096
--- Comment #10 from Rich Felker ---
Indeed, I think the POSIX requirement is both in conflict with the requirements
of the C language and a bad requirement in itself.
As for what GCC should do, since there room for debate about which behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87096
--- Comment #9 from Martin Sebor ---
(In reply to jos...@codesourcery.com from comment #7)
Thanks, that has some useful background.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87096
--- Comment #8 from Martin Sebor ---
The POSIX requirement prevents buffer overflow when the size of the destination
is incorrectly computed. I realize it's common practice to ignore snprintf
return value, but defensively written code should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87096
--- Comment #7 from joseph at codesourcery dot com ---
On Wed, 12 Dec 2018, msebor at gcc dot gnu.org wrote:
> I find the POSIX requirement to fail when n is greater than INT_MAX to be in
> conflict with C. I've submitted a defect to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87096
--- Comment #6 from Rich Felker ---
I don't see how the POSIX requirement makes the function safer. On the
contrary, it makes it less safe by introducing failure cases (that an
application might fail to check for, assuming it knows it has a good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87096
--- Comment #5 from Martin Sebor ---
I find the POSIX requirement to fail when n is greater than INT_MAX to be in
conflict with C. I've submitted a defect to the Austin Group:
http://austingroupbugs.net/view.php?id=1219
At the same time, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87096
--- Comment #4 from Rich Felker ---
I'm aware, but that makes it an invalid transformation. To be valid, the
transformation must only be performed in cases where it's provably not
exceptional.
The same principle applies to all the pathological
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87096
--- Comment #3 from Richard Biener ---
I don't think we "preserve" exceptional behavior consistently. That is, we
happily change code with exceptional behavior to code without if the main
computation result is the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87096
Andrew Pinski changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87096
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87096
Martin Sebor changed:
What|Removed |Added
Keywords||wrong-code
11 matches
Mail list logo
