This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/54582] gap in FORTIFY checking of buffer lengths
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 06 Feb 2013 12:41:09 +0000
- Subject: [Bug middle-end/54582] gap in FORTIFY checking of buffer lengths
- Auto-submitted: auto-generated
- References: <bug-54582-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54582
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-06 12:41:09 UTC ---
It isn't that easy. For %'s you really have to parse all the characters after
% and figure out where the format specifier ends. Users can have printf hooks
installed, so it certainly needs to give up any time it sees something it
doesn't fully understand. In that case I guess it could safely just assume the
lower bound as if the string ended on the % after which it doesn't understand
the letters. Note, that this is just about the compile time warning, the code
will fail at runtime the same way in the first as in the second case.
So, if we are going to do something about this, either we could do something
very simple, like strchr (str, '%') - str as low bound guess, or reuse the
c-format tables somehow (but they are in the FE, while this is in middle-end),
or write a simple parse of few most common formatting specifiers and give up on
anything else.