Re: PATCH: Add type_sprint() function to return type in string form

[Andrew Cagney <ac131313 at redhat dot com>]

> > You're kidding right?
> >
> > The ARI indicates that all sprintf calls should be replaced with either 
> > snprintf or xasprintf.
> >
> > Replacing sprintf with functions that are immune to buffer overrun 
> > problems, eliminates an entire class of bug.
> >
> > Even something as simple as:
> > 	char buf[100000000];
> > 	sprintf (buf, _("a"));
> > is broken.
>
>
> No, I'm not kidding.  I've worked in computer security for about six
> years now and I still use sprintf.  It's simple, it's effective, and if
> you use it reasonably carefully, nothing will go wrong.

That also applies to snprintf and xasprintf.

> Not to mention that there are a number of buggy implementations of
> snprintf; they're slowly starting to fade from use, thank the lord, but
> you still see 'em now and again.

If GDB encounters a system with a buggy snprintf implementation, it 
should use the one in libiberty.  If libiberty's is buggy, some one 
should fix it.

> Of course, in those six years I've had this argument about ten times. 
> It seems to be about a 50/50 split between developers.

> And nothing involving translation is simple.

There are tradeoffs.

Things like the 80/20 rule (80% of bugs fixed with 20% of the effort); 
zero tolerance (complete elimination of risky coding pratices).

This was seen with Kevin's recent elimination of of complain that 
flushed out numerous -Wformat problems.

As for replacing the existing sprintf calls, like STREQ et.al., anyone 
wanting to do this will need to come up with a way of demonstrating that 
the translation was `probably' correct.  One trick is to only convert 
lines that GCOV identifies as being executed.

Andrew