Re: [PATCH v2] gdb: add a numeric check after the exponent (PR cli/24124)

[Enze Li via Gdb-patches <gdb-patches@sourceware.org>]

Hi Tom,

Sorry for the delayed response.

On Fri, Sep 23 2022 at 07:47:51 AM -0600, Tom Tromey wrote:

>>>>>> "Enze" == Enze Li via Gdb-patches <gdb-patches@sourceware.org> writes:
>
>>> I suspect the change has to be in c-exp.y:parse_number, in order to
>>> support the case where the input radix is 16.  In this situation,
> Enze>                                             ^^
> Enze> Sorry, I didn't get that.  Shouldn't this radix be 10?
>
> No, what I mean is:
>
> (gdb) set input-radix 16
> Input radix now set to decimal 16, hex 10, octal 20.
> (gdb) print 80e
> $1 = 2062
>
> I think with your patch this will issue an error.

I got the same output as you metioned above with v2 of the patch
applied.  If I set input-radix to 16, the "input_radix"(line 2754)
variable is 16, and "hex" will be 1.  In this case, GDB assumes that the
"80e" is a hex number.  None of the following if and else-if conditions
are satisfied.  When GDB runs to line 2767, "hex" is still 1, this is vital.

......
2751    /* It's a number.  */
2752    int got_dot = 0, got_e = 0, got_p = 0, toktype;
2753    const char *p = tokstart;
2754    int hex = input_radix > 10;
2755    int exp_num = 0;
2756
2757    if (c == '0' && (p[1] == 'x' || p[1] == 'X'))
2758      {
2759        p += 2;
2760        hex = 1;
2761      }
2762    else if (c == '0' && (p[1]=='t' || p[1]=='T' || p[1]=='d' || p[1]=='D'))
2763      {
2764        p += 2;
2765        hex = 0;
2766      }
2767
......

Now, GDB runs to line 2773, the condition cannot be satisfied because
"hex" is 1, which means that "got_e" cannot be set to 1.  Then GDB runs
to line 2788, the judgment condition contains "got_e", and "got_e" is
now 0, which does not satisfy this condition, so it is not affected for
"80e".

......
2768	for (;; ++p)
2769	  {
2770	    /* This test includes !hex because 'e' is a valid hex digit
2771	       and thus does not indicate a floating point number when
2772	       the radix is hex.  */
2773	    if (!hex && !got_e && !got_p && (*p == 'e' || *p == 'E'))
2774	      got_dot = got_e = 1;
2775	    else if (!got_e && !got_p && (*p == 'p' || *p == 'P'))
2776	      got_dot = got_p = 1;
2777	    /* This test does not include !hex, because a '.' always indicates
2778	       a decimal floating point number regardless of the radix.  */
2779	    else if (!got_dot && *p == '.')
2780	      got_dot = 1;
2781	    else if (((got_e && (p[-1] == 'e' || p[-1] == 'E'))
2782		      || (got_p && (p[-1] == 'p' || p[-1] == 'P')))
2783		     && (*p == '-' || *p == '+'))
2784	      /* This is the sign of the exponent, not the end of the
2785		 number.  */
2786	      continue;
2787	    /* This is the digit of the exponent.  */
2788	    else if (got_e && *p >= '0' && *p <= '9')
2789	      exp_num++;
......

This is my understanding.  Did I miss something?

Best Regards,
Enze

>
> Enze> In addition, do these test cases below meet expectations?
>
> They seem fine to me.
>
> Tom