Re: [RFA] patch to remove language-dependent numeric output support

[Paul Hilfinger <hilfingr at EECS dot Berkeley dot EDU>]

 > Just some notes though:
 > > 	(local_decimal_format_custom): Remove.
 > > 	
 > > 	* utils.c: (int_string): New function.
 > I suspect that the the blank lines aren't needed - blank lines separate 
 >   commits rather than separate parts of the same commit - whichever.

Really?  OK.  Actually, I was putting in blank lines just to break up
a long ChangeLog entry, but if there's actually a convention, I'm
happy to follow it.

 > >       functions.  We have to split this up into separate print
 > > -     statements because local_hex_string returns a local static
 > > +     statements because hex_string returns a local static
 > 
 > can you file a bug report - that pre-existing behavior is a recipe for 
 > desaster :-(

And what do you think of the get_cell mechanism in utils.c?

Actually, I had considered changing the interface for that reason into 
something like:

	  hex_string (buffer, value)

and have hex_string return the result it puts into BUFFER (and
likewise for other functions, mutatis mutandis).  This would
require each hex_string client to supply the return space.  

 > Makefile.in will eventually need an update.  If you want to do it 
 > there's a script (gdb_makefile.in) hanging off of the ari web page that 
 > you might find useful.  Fixing the file is obvious.
 > I suspect that the special Makefile rule for printcmd.o can be deleted - 
 >   something for later.   Ditto.

Oops.  I had, in fact, intended to do this.

 > Again, thanks.  Now where were we with Ada.

That's a good question.  The only thing I've heard about at the moment
is that Joel mentioned that you had said something about the
architecture vector for language-specific types (I believe it was).  I
have got a patch for getting Ada to handle that the way C now does.

However, in the process, I've come up with a question about intended use:
Suppose one is in the evaluation code for language X and wants to use
built-in type FOO defined for language X.  What is the preferred way
to do so?  Calling language_lookup_primitive_type_by_name?  Seems a
shame to conduct a search in language-specific code when you know the
offset in that language's type vector:  is that how we're supposed to
do it instead, using values from an enumerated type such as enum
c_primitive_types?  Anyway, I can see several ways to do it, but the
intent is a little unclear.

Paul