Re: Fix for PR70498 in Libiberty Demangler

[Bernd Schmidt <bschmidt at redhat dot com>]

I've been looking through this patch. I had intended to commit it, but 
after looking through it a little more carefully I think there are a few 
things left to solve.

So, d_number/d_compact_number now return ints rather than longs, which 
makes sense since the lengths in things like struct demangle_component's 
s_name are integers. However, s_number there is defined as a long, so 
this does mean a tighter limit for things like 
d_template_param/d_make_template_param. Cc'ing Jason for an opinion on 
whether that's a problem or not (I suspect it isn't - t).

> -static long
> +static int
>   d_compact_number (struct d_info *di)
>   {
> -  long num;
> +  int num;
>     if (d_peek_char (di) == '_')
>       num = 0;
>     else if (d_peek_char (di) == 'n')
> @@ -2957,7 +2957,7 @@ d_compact_number (struct d_info *di)
>     else
>       num = d_number (di) + 1;
>
> -  if (! d_check_char (di, '_'))
> +  if (num < 0 || ! d_check_char (di, '_'))
>       return -1;
>     return num;
>   }

Shouldn't we check for overflows before performing the +1 addition (i.e. 
0 <= num < INT_MAX)? Ideally we'd also have a way to signal from 
d_number if we had an overflow while parsing that number.

There's also this, in d_expression_1:

	  index = d_compact_number (di) + 1;
	  if (index == 0)
	    return NULL;

which probably ought to have the same kind of check (I'll note that at 
this point we've accumulated two "+1"s, I'll assume that's what we want).

Please include a ChangeLog entry with the next patch.


Bernd