On 10/3/07, Julian Seward <[EMAIL PROTECTED]> wrote:
>
>
> > I'm wondering what is the right thing to do here. Having the format
> string
> > warnings is nice, but we should be consistent. Eg. when printing
> pointers,
> > should we use %p and cast to (void*) when necessary, instead of using
> > 0x%lx?
>
> In the long run fixing the format strings to keep gcc happy seems to me
> a good thing to do. Most of the fixing required is in reconciling
> Addr/Word/UWord args with %p formats, either by casting the arg to void*
> or changing the format to 0x%lx. Just occasionally gcc reports something
> more interesting, about too few arguments, or a fundamental type
> mismatch (32-bit int vs word-size int vs 64-bit int, etc).
>
> My concerns are:
>
> (1) that the output is not changed at all
>
> (2) it's a lot of boring work. Just a build for amd64-linux alone
> generates 1438 warnings that need to be fixed.
>
> (3) it's not worth doing unless we can be sure to get rid of all
> warnings when built with all versions of gcc we care about.
> Because I don't want to end up in a situation where a supposedly
> clean build still produces warnings. At least for valgrind 3.2.X
> I tried to ensure it would still build and work on RedHat 7.3, which
> uses gcc-2.96, so that's a pretty old compiler.
>
> Given these, and particularly (3), possibly a good solution is to do it
> on a svn branch, and, if it looks ok, merge it. After all, that is what
> branches are for.
>
> J
>
I agree with the concerns raised above. But regarding (3): how about the
warnings gcc emits on format strings like "%,d", which are supported by
Valgrind but which are not allowed by ANSI C ? I'm afraid every version of
gcc that supports format string checking will emit a warning on such format
strings. For an example of code that uses this kind of format
specifications, see e.g. memcheck/mc_malloc_wrappers.c.
Bart.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Valgrind-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
