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

[Maciej W. Rozycki]

On Mon, 28 Apr 2025, Joseph Myers wrote:

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

 Thank you.  I've already had a copy of N3220, but as you say it's already 
marked C2y and I have no immediate access to the updated C23 document with 
said editorial changes, so the resources I quote are the best in my 
possession I'm afraid.

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

 Hmm, isn't it the case that any wide character corresponds to exactly one 
multibyte character?  Are there multibyte characters that require multiple 
wide characters to encode?

 Arguably using the width to determine the number of multibyte characters 
rather than bytes read in the presence of the `l' length modifier is the 
only sane approach as otherwise the caller of `fscanf', etc. would have no 
means to determine how many wide characters have actually been written to 
storage pointed to by an argument corresponding to the `c' conversion 
specifier (and then `[' and `s' could follow for the sake of consistency 
although with those the terminating null character can be used to find out 
the length).  So I think it might be worth raising with the working group 
in addition to any usage analysis.

  Maciej