Commit Graph

3 Commits

Author SHA1 Message Date
Maciej W. Rozycki 5d45da09e6 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 11:53:31 +01:00
Maciej W. Rozycki 2d47b01de0 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 11:53:31 +01:00
Maciej W. Rozycki b692181703 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 17:42:12 +01:00