[PATCH 01/15] stdio-common: Don't read real input beyond the field width in scanf [BZ #13988]
Maciej W. Rozycki
macro@redhat.com
Mon Apr 28 21:46:09 GMT 2025
On Mon, 28 Apr 2025, Joseph Myers wrote:
> > "349) No special provisions are made for multibyte characters in the
> > matching rules used by the c, s, and [ conversion specifiers -- the extent
> > of the input field is determined on a byte-by-byte basis. The resulting
> > field is nevertheless a sequence of multibyte characters that begins in
> > the initial shift state."
> >
> > within § 7.23.6.2 "The fscanf function" on p. 339. I guess there are too
> > many versions around referred to as C23.
>
> C23 was published in October 2024, so you have an early draft missing a
> year and a half of changes. This is actually footnote 331. And that
Can you please point me at a document that's more recent than mine and
yet not past C23? I have a copy of a draft document dated June 2024 that
is already past (and marked C2y accordingly) where the footnote has number
330 and the text of which is identical (so any other changes made between
the two versions seem not to matter for this consideration).
> footnote doesn't seem to have much to do with the determination of field
> width (which as far as I can tell, is still a count of input bytes, for
What is "the extent of the input field" then in the footnote if not field
width?
> the narrow functions such as fscanf, even when the result is converted and
> stored in an array of wchar_t).
Well, the localedata/tst-bz12701-lc.c testcase from 06/15 contradicts it,
e.g. the call `fscanf (f, "%32lc%n", c, &n)' made there returns 38 in `n'
and moves the `f' stream's file position as many bytes forward. Have I
missed anything here or doesn't the field width count multibyte characters
rather than bytes there?
Maciej
More information about the Libc-alpha
mailing list