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

[Corinna Vinschen <vinschen@redhat.com>]

On Aug 18 09:50, Keith Packard wrote:
> 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.

Ok, pushed.

> other bugs:
> 
>  1. Assumes wchar_t is 2 bytes by setting the bytes remaining (_r) to 2.

That was an oversight.  A few lines above I had replaced that with
sizeof(wchar_t) but apparently forgot this line.  D'oh.

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

Given all chars are sizeof(wchar_t), how's the buffer ever going to
become unaligned?


Corinna