I need help with unconfirmed 49269: is there a workaround?

[Michael Kochetkov]

> > Hello,
> > I believe I have found the defect in libstdc++:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49269 but it is still
unconfirmed
> > within several weeks. So I wonder if one could help me with a workaround
> > for the problem?
> > The sample program prints "Current position: 1" for gcc and libstdc++
that
> > prevents the subsequent program normal working and VC with Dinkumware
> > prints "Current position: 2" and that is what I expect. It seems that
after
> > reading one wchar_t symbol the tellg function that returns position in
bytes
> > shall return 2. What do you think?
> > 
> > Thank you in advance,
> Like Paolo Carlini says in the bug report, this is very much
implementation defined behavior. 
> This means that even though two implementations give you different
results, they can very 
> well both be correct according to the standard.
>
> The way do_always_noconv() returns true, while do_encoding() returns 2,
seems a bit 
>inconsistent to me. If you need 2 external units to form 1 internal unit,
it looks like a conversion 
> to me.
The problem is that it looks like no one in the world can make libstdc++
streams handle UCS2 files with BOM. I have found the same problem with
www.boost.org -- https://svn.boost.org/trac/boost/ticket/5644 and they have
just given up.

I just hoped that libstdc++ or boost people would be able to help me with
that NullCodecvt class. But it looks like either nobody is interested or it
is just impossible to do with libstdc++'s streams a reliable way. At least I
was unable to find out a workable solution in internet.

--
Michael Kochetkov