Keith Packard <keithp@keithp.com> writes:

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

Never mind -- the wchar_t function cannot simply call the char version
as that would require converting to multi-byte so that EOF is handled
correctly, *and* would end up breaking the getchar function which
assumes that the unget buffer has wchar_t values, not multibyte values.

After looking at the code further and discovering numerous other bugs in
this path, I think we should just use the patch as submitted; I cannot
imagine a case where POSIX would change the semantics of scanf to ever
re-write the input with different characters.

other bugs:

 1. Assumes wchar_t is 2 bytes by setting the bytes remaining (_r) to 2.

 2. Computes the pointer value by subtracting the wchar_t size from the
    _ubuf size, resulting in an unaligned pointer. Then uses this
    pointer directly in both getwc and ungetwc, which will cause a bus
    error on processors unable to access unaligned data.

We could also simplify the matching code path in vfscanf.c at some
point.

-- 
-keith