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

[Andrew Cagney]

>> 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