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

Keith Packard <[email protected]> Wed, 18 Aug 2021 09:30:17 -0700

Newsgroups	gmane.comp.lib.newlib
Message-ID	<[email protected]>

Corinna Vinschen <[email protected]> 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

signature.asc (application/pgp-signature, 832 B)