This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Martin Sebor <msebor at gmail dot com>
- Cc: Richard Biener <rguenther at suse dot de>, Gcc Patch List <gcc-patches at gcc dot gnu dot org>, Joseph Myers <joseph at codesourcery dot com>
- Date: Mon, 4 Jul 2016 18:44:21 +0200
- Subject: Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)
- Authentication-results: sourceware.org; auth=none
- References: <5776B33E.2080504@gmail.com> <alpine.LSU.2.11.1607041255060.29772@t29.fhfr.qr> <577A8D6A.3070902@gmail.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Mon, Jul 04, 2016 at 10:23:06AM -0600, Martin Sebor wrote:
> >>1) Making use of -Wformat machinery in c-family/c-format.c. This
> >> seemed preferable to duplicating some of the same code elsewhere
> >> (I initially started implementing it in expand_builtin in
> >> builtins.c). It makes the implementation readily extensible
> >> to all the same formats as those already handled for -Wformat.
> >> One drawback is that unlike in expand_builtin, calls to these
> >> functions cannot readily be folded. Another drawback pointed
> >
> >folded? You mean this -W option changes code generation?
>
> No, it doesn't. What I meant is that the same code, when added
> in builtins.c instead, could readily be extended to fold into
> strings expressions like
>
> sprintf (buf, "%i", 123);
I've commented in some PR a few years ago that I'm not convinced we want to
do it, or at least not without careful considerations, consider .rodata
size. Say if the user has in 1000x different places
sprintf (buf, "foobarbaz %i", NNN); for various values of NNN, then such "optimization" would replace
a single string literal of length 13 bytes with 1000 string literals of 12-20 bytes.
Consider larger string literal, with %s and long additions and it might not
be a win even for 2 occurrences.
Jakub