[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