Signed-off-by: Alejandro Colomar <alx@kernel.org>
Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

Unicode 17.0.0 Support: Character encoding, character type info, and
transliteration tables are all updated to Unicode 17.0.0, using
the generator scripts contributed by Mike FABIAN (Red Hat).

Changes in CHARMAP and WIDTH:

    Total added characters in newly generated CHARMAP: 4803
    Total removed characters in newly generated WIDTH: 0
    Total changed characters in newly generated WIDTH: 0
    Total added characters in newly generated WIDTH: 4512

Some combining characters and other non-spacing marks have been added
with WIDTH 0. Lots of characters have been added with WIDTH 2, most of
them are CJK Ideographs plus a few Tangut characters and 7 emoji.

Changes in ctype:

    alpha: Added 4672 characters in new ctype which were not in old ctype
    combining: Added 42 characters in new ctype which were not in old ctype
    combining_level3: Added 8 characters in new ctype which were not in old ctype
    graph: Added 4803 characters in new ctype which were not in old ctype
    lower: Missing: ʕ 0x295 LATIN LETTER PHARYNGEAL VOICED FRICATIVE
    lower: Added 27 characters in new ctype which were not in old ctype
    print: Added 4803 characters in new ctype which were not in old ctype
    punct: Added 131 characters in new ctype which were not in old ctype
    tolower: Added 28 characters in new ctype which were not in old ctype
    totitle: Added 28 characters in new ctype which were not in old ctype
    toupper: Added 28 characters in new ctype which were not in old ctype
    upper: Added 28 characters in new ctype which were not in old ctype

Nothing suspicious in the additions.

About the character removed from lower:

ʕ 0x295 LATIN LETTER PHARYNGEAL VOICED FRICATIVE

In UnicodeData.txt it changed from 'Ll' (Letter Lowercase) to 'Lo' (Letter Other):

-0295;LATIN LETTER PHARYNGEAL VOICED FRICATIVE;Ll;0;L;;;;;N;LATIN LETTER REVERSED GLOTTAL STOP;;;;
+0295;LATIN LETTER PHARYNGEAL VOICED FRICATIVE;Lo;0;L;;;;;N;LATIN LETTER REVERSED GLOTTAL STOP;;;;

Resolves: BZ #33289

Reviewed-by: Collin Funk <collin.funk1@gmail.com>

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>

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>

Reject invalid formatted scanf character data with the 'c' conversion
where there is not enough input available to satisfy the field width
requested.  It is required by ISO C that this conversion matches a
sequence of characters of exactly the number specified by the field
width and it is also already documented as such in our own manual:

"It reads precisely the next N characters, and fails if it cannot get
that many."

Currently a matching success is instead incorrectly produced where the
EOF condition is encountered before the required number of characters
has been retrieved, and the characters actually obtained are stored in
the buffer provided.

Add test cases accordingly and remove placeholders from 'c' conversion
input data for the existing scanf tests.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

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>

On a Linux system you have two sources for locales: glibc and ICU.

ICU offeres a lot more languages than glibc. Especially when it comes to
en_*.

If you have an English system and want to use ISO8601 for date and time
format there is only one locale which can be used for that: en_SE

However ICU offers en_SE and glibc doesn't. If you set LC_TIME=en_SE a
lot of application wont start, because the locale is not known to glibc.

https://sourceware.org/bugzilla/show_bug.cgi?id=33190

Signed-off-by: Andreas Schneider <asn@cryptomilk.org>

Reviewed-by: Mike FABIAN <mfabian@redhat.com>

Fix an erratum in the Persian locale claiming that the CLDR collation
rules referred are for Ukrainian.

There are some spelling mistakes in the test file. Fix them

Reviewed-by: guoce <guoce@kylinos.cn>
Signed-off-by: panzhe0328 <panzhe@kylinos.cn>
Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

Fix the handling of real 'scanf' input such as "+.e" as per BZ #13988
for the i18n case as well, complementing commit 6ecec3b616ae ("Don't
accept exp char without preceding digits in scanf float parsing"), where
the 'e' character is incorrectly consumed from input.  Add a test case
matching stdio-common/bug26.c, with bits from localedata/tst-sscanf.c.

Reviewed-by: Joseph Myers <josmyers@redhat.com>