[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: security format patch

From: Ivailo
Subject: Re: security format patch
Date: Mon, 2 Dec 2013 20:15:15 +0000

Strange enough, I can't reproduce it either the way you describe.
Not even with my usual build flags that I used to build diffutils
which test suites fails and I saw that it uses gnulib that lead me
here. If you can try to actually build and check diffutils (3.3) maybe
you will be able to reproduce it as I have no idea if diffutils applies
some custom configuration that may lead to the failure but is
actually filtered somewhere in gnulib itself (which would be very
strange). I will try to build diffutils from latest git checkout which will
bootstrap gnulib to see how that goes.

But anyway, patch that uses #pragma attached. As I'm not
entirely sure how this will actually work the patch may not be good
enough - I do not know if it will filter "-Wformat-nonliteral" literally
from the build flags or the interpretation of it, for an example, of
what "-Wformat-security" is supposed to do. So, maybe additional
pragmas, e.g. for "-Wformat", may be needed which will actually
turn of all format warnings must be used (altough that may not be
the best thing to do).

If anyone can come up with better patch and fix the issue that would
be great.


On Mon, Dec 2, 2013 at 7:40 PM, Paul Eggert <address@hidden> wrote:
On 12/02/2013 11:18 AM, Eric Blake wrote:
> So the correct fix is the use
> of #pragma GCC diagnostic to shut up the compiler's warning

Another possibility is to use obscurer code that GCC
can't figure out; that's what we did for the empty-string

I can't reproduce the problem on my
platform (Fedora 19 with its GCC 4.8.2).  Here's how I
tried to reproduce it:

./gnulib-tool --create-testdir --dir foo xvasprintf
cd foo
./configure CFLAGS='-Wformat -Werror=format-security -O2'
make check

Attachment: format-security.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]