[PATCH 01/15] stdio-common: Don't read real input beyond the field width in scanf [BZ #13988]

[Joseph Myers]

On Mon, 28 Apr 2025, Maciej W. Rozycki wrote:

> > 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).

N3220 is a C2Y draft with only one editorial change after it branched from 
C23.  (However, there were hundreds of editorial changes in C23 postdating 
N3220 because of the many rounds of editorial iteration with ISO required 
in the publication process.)

> > 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?

This sounds like a case for a more detailed analysis of what different 
implementations do (counting bytes versus multibyte characters) with a 
view to possibly reporting an issue against that standard.  Though it 
should be noted that for effective control of how much gets written to the 
array, *number of wide characters written* can in general be greater than 
*number of multibyte characters read*, so it's not entirely clear either 
is the best answer.

-- 
Joseph S. Myers
josmyers@redhat.com