Re: lib/47602 (getwc() modifies input instead of returning EILSEQ.)

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

> On Jan 21,  2:07am, yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi) wrote:
> -- Subject: Re: lib/47602 (getwc() modifies input instead of returning EILSEQ
> 
> | do you mean to expect the "c == obuf[i]" test always true?
> 
> If that's not true, many things turn quickly very complicated, because
> you cannot read and write a file using getwc() and write it using putwc()
> and expect it to work. If I know that wchar_t is 2 bytes and I call 2
> getc()'s I can expect to get the next two bytes from the file I think.

it's expected to work if you do putwc and getwc within the same locale.

> 
> | while obuf[] is wchar_t for big5 locale (right?), what getwc returns
> | is wchar_t for another locale.  comparing them with "==" doesn't make
> | much sense.
> 
> Right, but I am not sure if this is such a great idea.
> 
> | (i'm not sure about the intention of the mixed use of getwc and getc
> | in the program, though.)
> 
> I did not write this, but I think the logic is, read with getwc() and
> if that fails, skip the next 2 bytes with getc() and keep going. How
> else do you recover? Bail for the rest of the file, because two bytes
> got corrupted?

thanks for explanation.

you can probably recover in that way except that it's in general
difficult to make a correct guess how many bytes to skip.
besides that, probably it's safer to use fgetpos/fsetpos to recover
the position.

C locale is not rich enough for programs like editors.

YAMAMOTO Takashi

> 
> christos