On Wed, Oct 31, 2007 at 01:29:51PM +0100, Abdelrazak Younes wrote: > Enrico Forestieri wrote: > > On Wed, Oct 31, 2007 at 08:22:44AM +0100, Abdelrazak Younes wrote: > >> Enrico Forestieri wrote: > >>> On Tue, Oct 30, 2007 at 06:26:45PM +0100, Jürgen Spitzmüller wrote: > >>>> http://bugzilla.lyx.org/show_bug.cgi?id=4147 > >>>> > >>>> The bug is the result of an encoding failure (use of char instead of > >>>> char_type) that results in an unwanted conversion of a tabulator ('\t') > >>>> to > >>>> the digit '9'. > >>>> > >>>> I'll commit to branch and trunk on Friday if I get no objections. > >>> This is not going to work on systems where sizeof(wchar_t) == 2. > >>> I have attached a better fix to bug 4147 on bugzilla. > >> I'm afraid your patch could have some bad effect and could hide future > >> bugs because the stream is not strongly typed anymore. I am not sure > >> about that but please make sure that is not the case. > > > > Uh? > > Something you didn't understand in my explanation? > > I mean that if the passed something that is not strictly ASCII we may > have problem later. So, WRT your patch, I'll add an assertion there to > make sure this won't happen: > > Index: src/support/docstream.h > =================================================================== > --- src/support/docstream.h (revision 21296) > +++ src/support/docstream.h (working copy) > @@ -77,6 +77,13 @@ odocstream & operator<<(odocstream & os, > return os; > } > > +inline > +odocstream & operator<<(odocstream & os, unsigned char c) > +{ > + BOOST_ASSERT(c < 0x80); > + os.put(c); > + return os; > +} > + > > Clearer?
Not really. UCS-4 code points from 0x0000 to 0x00ff exactly correspond to latin-1 code points. So unsigned char c = 0xb5; os.put(c); gives me a 'µ' character, and the assertion above is wrong. Maybe you have utf8 in mind. -- Enrico
