Re: [ob] More warnings; Call for assistance

[Daniel Jacobowitz <drow@false.org>]

On Tue, Jan 17, 2006 at 10:11:12PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 17 Jan 2006 14:46:24 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > 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
> 
> These aren't crashes, GDB prints a legible error message and returns
> to top level.  However, internal_error is not the best idea for these
> situations, so we probably should arrange for GDB to mutter something
> about possibly bad format instead, and not to ask whether to dump
> core.

I suppose that would work.  And be a good idea if we're not going to
make any other changes here, along with -Wformat-nonliteral.

For reference, it'd actually be "removing -Wformat-nonliteral".  An
earlier message in this thread confused me about what that option did.

> > The advantages of static format checking, in the face of that, are
> > pretty large.
> 
> No matter what you do, as long as users are typing format strings, it
> will always be possible for a format to exceed our wildest
> imagination.  You cannot beat that, unless you are willing to
> artificially restrict users to some safe and/or easily parsable subset
> of valid formats, which I think we shouldn't do.
> 
> > avoid the use of standard printf
> 
> Avoid? how? are you saying that we should write our own version of
> printf?

Certainly we shouldn't write a new one - but the advantage of being a
GNU project and licensed under the GPL is that there's already at least
two we can choose from, probably more :-)

Another major advantage of having our own implementation of printf is that
we could document which format specifiers the GDB "printf" command
supports.  Right now we say "it's the same as if your program had
called printf", which is not necessarily true, e.g. with remote
debugging.

This is what I'd been vaguely planning on doing, but never gotten
around to.

-- 
Daniel Jacobowitz
CodeSourcery