Does monitor.c work?

[Andrew Cagney]

Hello,

monitor.c is based around a table of format strings vis:

   m32r_cmds.set_break = "%x +bp\r";     /* set a breakpoint */
   m32r_cmds.clr_break = "%x -bp\r";     /* clear a breakpoint */

(this is definitly far from unique to the m32r).  Those format strings 
are then passed to a printf like routine vis:

monitor_printf (char *pattern,...)
...
monitor_insert_breakpoint (CORE_ADDR addr, char *shadow)
...
           monitor_printf (current_monitor->set_break, addr);

The problem, in monitor_vsprintf (which monitor_printf calls) is that 
the CORE_ADDR is extracted as a long vis:

             default:
               arg_int = va_arg (args, long);
               sprintf (sndbuf, format, arg_int);
               break;

I'm guessing that on the little-endian i386 va_arg(long) and 
va_arg(longlong) just happen to pick up the same leading bytes leaving 
people with the impression that things ``work''.  Arrrgh!!!!!!

Looking at the file, GraceS has started the correct trend by adding a 
method (replaced a constant array).
     const char *(*regname) (int index);
I think all format strings (the ones that take parameters) should be 
converted into explicit methods.

Andrew

PS: Arrrg!!!
PPS: This means that I'm not going to try to fix monitor.c's 
-Wformat-nonliteral warnings.