Re: Patch: printing java `char' values

[Michael Snyder <msnyder@redhat.com>]

Tom Tromey wrote:
> 
> >>>>> "Michael" == Michael Snyder <msnyder@redhat.com> writes:
> 
> Michael> D'oh.  I just remembered -- GDB always labels chars as
> Michael> "TYPE_CODE_INT".  Sorry I didn't think about it earlier.
> 
> Don't worry -- I'm just happy anybody read the patch.
> 
> Michael> TYPE_CODE_INT is more of a class than a type.  It includes
> Michael> all integer-like types, including char, short, int, long, and
> Michael> long long.
> 
> Michael> I've no idea what context TYPE_CODE_CHAR might be used in.
> 
> Ok.  Does this mean my patch is ok?  Or is there something better way
> to do it?

Hmmm, looking at it now.

I see that none of the symbol readers except for stabsread.c will ever
create a TYPE_CODE_CHAR node.  And stabs does it only in a special 
circumstance (and only for the RS/6000).  So you're unlikely to get
symbol info that says that your variable is a TYPE_CODE_CHAR.
That's probably why you're seeing it as TYPE_CODE_INT (which in my
experience is normal).

I recommend that you emulate what C does, and whenever you have a
TYPE_CODE_INT whose length is the length of a char (which for Java
appears to be two bytes), you look at the type_name and see if it is
"char" -- in which case you print it as a char.  Umm, which appears
to be exactly what you're doing -- except that I'd be inclined to 
put the test within the 
	case TYPE_CODE_INT:
block, rather than meddle with state before the switch statement.
That appears to be what the other language modules do.

Michael