[PATCH] svfwscanf: Simplify _sungetwc_r to eliminate apparent buffer overflow

[Keith Packard]

Corinna Vinschen <vinschen@redhat.com> writes:

> LGTM.  Under the unlikely assumption that wscanf gets extended in future
> and has to ungetc a char different from the input char, how do we catch
> that?  Do we need a hint, somehow, somewhere?

I can't imagine a case where that wouldn't be a bug; the only reason I
know that ungetc takes the old char is because stdio might not still
have it in the buffer, and that can't happen for string sources.

However, I also don't know how we'd catch this bug at compile time, and
having the string source work differently in this case than the file
source means testing using string sources might not uncover a bug that
would appear with file sources.

A reasonable alternative would be to have the wchar_t version call the
char version multiple times, instead of just doing it inline; that would
avoid any semantic difference, which seems like a feature. I'll post a
patch that does it this way shortly and see which you prefer.

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/newlib/attachments/20210818/640fc16d/attachment.sig>