RE: [RFC] Stabs parsing regression from GDB 6.6 to GDB 6.6.90

["Pierre Muller" <muller@ics.u-strasbg.fr>]

  Did you change the read_huge_number.s file manually?
It is as if there is an typing error for the
u16 type definition.
	.stabs	"s16:t(0,24)=@s16;r(0,24);0100000;077777;",128,0,0,0
	.stabs	"u16:t(0,25);r(0,25);0000000;0177777;",128,0,0,0
the ';' before 'r(0,25)' should be an equal sign, no?

  One difference between my patch and yours is
that I think that your patch will mishandle 
any octal number having more digits than needed,
because you are always considering that the 
first char after the leading zero (to trigger octal notation)
contains the sign bit.
  For instance, your patch does not complaint about this
	.stabs	"t30:t(0,30)=@s8;r(0,30);02000;0077;",128,0,0,0
but 02000 is -1024 and does not fit into a 8 bit memory.

  I agree that there are normally no reasons to have more digits,
but more  leading zeroes should not lead to an error in the parsing
and any bit set higher that this should trigger an error.

  By the way, why is read_huge_number returning a 'long'?
It should be much better to return a LONGEST 
 LONGEST_MAX also exists, so switching 
the type of that function to read_huge_number
would allow to get correct results much more often.

  The main interest would be to really get the 
real upper and lower bounds of range type
even if they do not fit into 'long' type.
  These fields are currently put into
TYPE_FIELD_BITPOS which is a 'long' type
but this is in a union so adding one more field 
on type 'LONGEST' and name 'bound',
adding a TYPE_FIELD_BOUND macro would be 
easier to read but would increase the 'field_location'
element of the 'type' structure.
  Another solution would be to
create a pointer to a 'LONGEST' value,
which would remove an increase of the general
'type' struct size.

Pierre Muller