Re: [ob] More warnings; Call for assistance

[Daniel Jacobowitz <drow@false.org>]

On Tue, Jan 17, 2006 at 11:37:29AM -0800, Jim Blandy wrote:
> Looking at the printcmd.c warnings, there's the following note in Makefile.in:
> 
> # FIXME: cagney/2003-08-10: Do not try to build "printcmd.c" with
> # -Wformat-nonliteral.  It needs to be overhauled so that it doesn't
> # pass user input strings as the format parameter to host printf
> # function calls.
> printcmd.o: $(srcdir)/printcmd.c
> 	$(CC) -c $(INTERNAL_WARN_CFLAGS) $(NO_WERROR_CFLAGS) $(srcdir)/printcmd.c
> 
> I gather what this is suggesting is that we have a big switch
> selecting an appropriate call to printf that uses a fixed format
> string.
> 
> There will be dozens of cases there, due to the modifiers (h, l, ll,
> precision, leading sign, alternative form).  The precisions will need
> to be parsed when present; sometimes they are minimum values,
> sometimes they are maximum values.  Since we check the number and type
> of the arguments, I think -Wformat-nonliteral is the right answer
> here.  I don't see a benefit to making this change that justifies the
> risk of mistakes.
> 
> What do folks think?

I disagree, because (IIRC) Debian users have filed at least two bugs
where failures in this code have led to user input crashing GDB:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186037
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=231162

The advantages of static format checking, in the face of that, are
pretty large.  If we can simplify this or else avoid the use of
standard printf, we won't have these kinds of bugs.

However, I'd strongly prefer to address the pointer problems first
before returning to worry around the edges of this one :-)

-- 
Daniel Jacobowitz
CodeSourcery