qiurui
/
glibc
mirror of git://sourceware.org/git/glibc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
glibc/localedata/tst-scanf-width-point.c

54 lines
1.6 KiB
C
Raw Normal View History

stdio-common: Don't read real input beyond the field width in scanf Fix a code pattern that repeats across '__vfscanf_internal' where the remaining field width of 0 is incorrectly interpreted as no width limit, which in turn results in reading input beyond the limit requested. The lack of width limit is indicated by the field width of -1 rather than 0, set earlier on in the function. The problematic code pattern is used for both integer and floating-point conversions, but in the former case a corresponding conditional earlier on prevents the field width from being 0 when executing the pattern. It does trigger in the latter case, where the decimal point is a multibyte character or for multibyte digit characters. Fix the code pattern by using 'width > 0' comparison, and apply the fix throughout even to code handling integer conversions so as to interpret the field width consistently and avoid people's confusion even if width cannot be 0 at those places. For multibyte digit characters there is an additional issue that causes code to push back a partially fetched multibyte character multiple times as execution proceeds through matching data retrieved against individual digits that have to be rejected due to the field width limit preventing the rest of the multibyte character from being retrieved. It is because code relies on 'ungetc' ignoring a request to push back EOF, however in the out-of-limit field width condition the data held is not EOF but the previously retrieved character byte instead. Fix this issue by artificially assigning EOF to the character byte storage variable where the out-of-limit field width condition prevents further processing, and also apply the fix throughout except for the decimal point/thousands separator case, which uses different code. Add test cases accordingly. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
2025-08-11 16:42:12 +00:00
/* Verify multibyte decimal point extending beyond scanf field width.
Copyright (C) 2025 Free Software Foundation, Inc.
This file is part of the GNU C Library.
The GNU C Library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
The GNU C Library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with the GNU C Library; if not, see
<https://www.gnu.org/licenses/>. */
#include <locale.h>
#include <stdio.h>
#include <string.h>
#include <libc-diag.h>
#include <support/check.h>
testsuite: Update tests for 'xfmemopen' use Convert tests to use 'xfmemopen' rather than open-coding error checks with 'fmemopen' or plain missing them, where 'fmemopen' itself is not the scope of testing. Leave 'fmemopen' tests alone. Reviewed-by: Florian Weimer <fweimer@redhat.com>
2025-09-05 10:53:31 +00:00
#include <support/xstdio.h>
stdio-common: Don't read real input beyond the field width in scanf Fix a code pattern that repeats across '__vfscanf_internal' where the remaining field width of 0 is incorrectly interpreted as no width limit, which in turn results in reading input beyond the limit requested. The lack of width limit is indicated by the field width of -1 rather than 0, set earlier on in the function. The problematic code pattern is used for both integer and floating-point conversions, but in the former case a corresponding conditional earlier on prevents the field width from being 0 when executing the pattern. It does trigger in the latter case, where the decimal point is a multibyte character or for multibyte digit characters. Fix the code pattern by using 'width > 0' comparison, and apply the fix throughout even to code handling integer conversions so as to interpret the field width consistently and avoid people's confusion even if width cannot be 0 at those places. For multibyte digit characters there is an additional issue that causes code to push back a partially fetched multibyte character multiple times as execution proceeds through matching data retrieved against individual digits that have to be rejected due to the field width limit preventing the rest of the multibyte character from being retrieved. It is because code relies on 'ungetc' ignoring a request to push back EOF, however in the out-of-limit field width condition the data held is not EOF but the previously retrieved character byte instead. Fix this issue by artificially assigning EOF to the character byte storage variable where the out-of-limit field width condition prevents further processing, and also apply the fix throughout except for the decimal point/thousands separator case, which uses different code. Add test cases accordingly. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
2025-08-11 16:42:12 +00:00
#define PD "\xd9\xab"
static int
do_test (void)
{
if (setlocale (LC_ALL, "ps_AF.UTF-8") == NULL)
FAIL_EXIT1 ("setlocale (LC_ALL, \"ps_AF.UTF-8\")");
char s[] = "1" PD;
testsuite: Update tests for 'xfmemopen' use Convert tests to use 'xfmemopen' rather than open-coding error checks with 'fmemopen' or plain missing them, where 'fmemopen' itself is not the scope of testing. Leave 'fmemopen' tests alone. Reviewed-by: Florian Weimer <fweimer@redhat.com>
2025-09-05 10:53:31 +00:00
FILE *f = xfmemopen (s, strlen (s), "r");
stdio-common: Don't read real input beyond the field width in scanf Fix a code pattern that repeats across '__vfscanf_internal' where the remaining field width of 0 is incorrectly interpreted as no width limit, which in turn results in reading input beyond the limit requested. The lack of width limit is indicated by the field width of -1 rather than 0, set earlier on in the function. The problematic code pattern is used for both integer and floating-point conversions, but in the former case a corresponding conditional earlier on prevents the field width from being 0 when executing the pattern. It does trigger in the latter case, where the decimal point is a multibyte character or for multibyte digit characters. Fix the code pattern by using 'width > 0' comparison, and apply the fix throughout even to code handling integer conversions so as to interpret the field width consistently and avoid people's confusion even if width cannot be 0 at those places. For multibyte digit characters there is an additional issue that causes code to push back a partially fetched multibyte character multiple times as execution proceeds through matching data retrieved against individual digits that have to be rejected due to the field width limit preventing the rest of the multibyte character from being retrieved. It is because code relies on 'ungetc' ignoring a request to push back EOF, however in the out-of-limit field width condition the data held is not EOF but the previously retrieved character byte instead. Fix this issue by artificially assigning EOF to the character byte storage variable where the out-of-limit field width condition prevents further processing, and also apply the fix throughout except for the decimal point/thousands separator case, which uses different code. Add test cases accordingly. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
2025-08-11 16:42:12 +00:00
/* This should succeed parsing a floating-point number, and leave '\xd9',
'\xab' in the input. */
double d;
int c;
TEST_VERIFY_EXIT (fscanf (f, "%2lf%n", &d, &c) == 1);
TEST_VERIFY_EXIT (d == 1.0);
TEST_VERIFY_EXIT (c == 1);
TEST_VERIFY_EXIT (fgetc (f) == 0xd9);
TEST_VERIFY_EXIT (fgetc (f) == 0xab);
testsuite: Update tests for 'xfclose' use Convert (some) tests to use 'xfclose' rather than using plain 'fclose' call with no error checking or plain missing such a call. Reviewed-by: Florian Weimer <fweimer@redhat.com>
2025-09-05 10:53:31 +00:00
xfclose (f);
stdio-common: Don't read real input beyond the field width in scanf Fix a code pattern that repeats across '__vfscanf_internal' where the remaining field width of 0 is incorrectly interpreted as no width limit, which in turn results in reading input beyond the limit requested. The lack of width limit is indicated by the field width of -1 rather than 0, set earlier on in the function. The problematic code pattern is used for both integer and floating-point conversions, but in the former case a corresponding conditional earlier on prevents the field width from being 0 when executing the pattern. It does trigger in the latter case, where the decimal point is a multibyte character or for multibyte digit characters. Fix the code pattern by using 'width > 0' comparison, and apply the fix throughout even to code handling integer conversions so as to interpret the field width consistently and avoid people's confusion even if width cannot be 0 at those places. For multibyte digit characters there is an additional issue that causes code to push back a partially fetched multibyte character multiple times as execution proceeds through matching data retrieved against individual digits that have to be rejected due to the field width limit preventing the rest of the multibyte character from being retrieved. It is because code relies on 'ungetc' ignoring a request to push back EOF, however in the out-of-limit field width condition the data held is not EOF but the previously retrieved character byte instead. Fix this issue by artificially assigning EOF to the character byte storage variable where the out-of-limit field width condition prevents further processing, and also apply the fix throughout except for the decimal point/thousands separator case, which uses different code. Add test cases accordingly. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
2025-08-11 16:42:12 +00:00
return 0;
}
#include <support/test-driver.c>