Re: [Valgrind-developers] valgrind: r6928 - trunk/coregrind

[Bart V. A. <bar...@gm...>]

On 10/3/07, Julian Seward <js...@ac...> 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.