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

[Joseph Myers]

On Tue, 29 Apr 2025, Maciej W. Rozycki wrote:

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

See the example discussed in bug 25744 of Big5-HKSCS multibyte characters 
that convert to two wide characters.  Dealing better with such cases was 
one of the motivations for C2Y stdmchar.h.

(Such cases are more generally an issue for implementations that use 
UTF-16 as their wchar_t, but that's not relevant to glibc.)

-- 
Joseph S. Myers
josmyers@redhat.com