[PATCH] math: enhance the endloop condition of function handle_input_flag

[PATCH] math: enhance the endloop condition of function handle_input_flag

[liqingqing]

     review the source code of function "handle_input_flag" and found 
that the endloop condition is not correct,
cause when the loop variable " i " euqal to 16, then the input_flags[16] 
will be out of bounds.
though I  think for now the inputs maybe all right, but just enhanced it.

---
  math/gen-auto-libm-tests.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/math/gen-auto-libm-tests.c b/math/gen-auto-libm-tests.c
index f15af29a4e0..08684c4646d 100644
--- a/math/gen-auto-libm-tests.c
+++ b/math/gen-auto-libm-tests.c
@@ -1298,7 +1298,7 @@ handle_input_flag (char *arg, input_flag *flag,
    char c = *ep;
    *ep = 0;
    bool found = false;
-  for (input_flag_type i = flag_first_flag; i <= num_input_flag_types; i++)
+  for (input_flag_type i = flag_first_flag; i < num_input_flag_types; i++)
      {
        if (strcmp (arg, input_flags[i]) == 0)
      {
-- 
2.23.0.windows.1

Re: [PATCH] math: enhance the endloop condition of function handle_input_flag

[Joseph Myers]

[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

On Mon, 28 Oct 2019, liqingqing wrote:

>     review the source code of function "handle_input_flag" and found that the
> endloop condition is not correct,
> cause when the loop variable " i " euqal to 16, then the input_flags[16] will
> be out of bounds.
> though I  think for now the inputs maybe all right, but just enhanced it.

Thanks, committed with a somewhat edited commit message.  Note: I had to 
apply the patch manually as it appears your mailer inserted some Unicode 
space characters in it.  Patches inserted in the body of an email need to 
be verbatim with no whitespace changes from the email client for it to be 
possible to apply them, so if that's a problem they should be attached 
rather than included directly in the body of the email.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH] math: enhance the endloop condition of function handle_input_flag

[liqingqing]

On 2019/11/7 8:32, Joseph Myers wrote:
> On Mon, 28 Oct 2019, liqingqing wrote:
> 
>>      review the source code of function "handle_input_flag" and found that the
>> endloop condition is not correct,
>> cause when the loop variable " i " euqal to 16, then the input_flags[16] will
>> be out of bounds.
>> though I  think for now the inputs maybe all right, but just enhanced it.
> 
> Thanks, committed with a somewhat edited commit message.  Note: I had to
> apply the patch manually as it appears your mailer inserted some Unicode
> space characters in it.  Patches inserted in the body of an email need to
> be verbatim with no whitespace changes from the email client for it to be
> possible to apply them, so if that's a problem they should be attached
> rather than included directly in the body of the email.
> 

hello joseph, thanks for the improvement suggestions to me, this patch 
was maked by "git format-patch" and sent to the libc-alpha maillist  was 
used by "git send-email" in a windows git-bash enviornment. I think i 
need to check my configuration again and find what happend. thank you.

Re: [PATCH] math: enhance the endloop condition of function handle_input_flag

[liqingqing]

On 2019/11/7 8:32, Joseph Myers wrote:
> On Mon, 28 Oct 2019, liqingqing wrote:
> 
>>     review the source code of function "handle_input_flag" and found that the
>> endloop condition is not correct,
>> cause when the loop variable " i " euqal to 16, then the input_flags[16] will
>> be out of bounds.
>> though I  think for now the inputs maybe all right, but just enhanced it.
> 
> Thanks, committed with a somewhat edited commit message.  Note: I had to 
> apply the patch manually as it appears your mailer inserted some Unicode 
> space characters in it.  Patches inserted in the body of an email need to 
> be verbatim with no whitespace changes from the email client for it to be 
> possible to apply them, so if that's a problem they should be attached 
> rather than included directly in the body of the email.
> 

I think maybe the default_charset is not utf-8?