using bool in rtl::OUStringBuffer::append

Lubos Lunak l.lunak at
Thu Oct 4 04:18:07 PDT 2012

On Thursday 04 of October 2012, Stephan Bergmann wrote:
> On 10/04/2012 07:49 AM, Noel Grandin wrote:
> > On 2012-10-03 22:03, Stephan Bergmann wrote:
> >>> places. The commit seems to have caused some test failures and
> >>> crashes. I reverted it for now.
> >>
> >> ...which only goes to show what a horrible mess C++ is in practice.
> >> bool is rather special, but you easily forget to consider all the
> >> consequences of that.  Turns out that code like
> >>   aBuf.append( pElementType->pTypeName );
> >> (typelib_static_sequence_type_init,
> >> cppu/source/typelib/static_types.cxx), where pElementType->pTypeName
> >> is of type rtl_uString*, now chooses for overload resolution the
> >> standard boolean conversion from rtl_uString* to bool (yielding true,
> >> so appending "true" to aBuf) rather than the user-defined conversion
> >> by constructor from rtl_uString* to rtl::OUString.
> >
> > Can that be fixed by adding an
> >     OUStringBuffer::append( rtl_uString* )
> > method, which does the necessary conversion internally?
> That would solve this specific incident, but who knows what other,
> similar problems with other types would still be lurking.

 I do. The only pointer type used this way with OUStringBuffer::append() is 
_rtl_uString. That's the good news, the bad news is that there is also const 
char* that should not be used this way, and adding such an overload would 
break the string literal overloads. I suppose this all could be solved using 
bool and _rtl_uString* overloads, and by making a tinderbox use a compiler 
plugin that checks that const char* arguments are not passed to the bool 
overload, but I'm not quite sure the bool overload is worth the effort.

 Lubos Lunak
 l.lunak at

More information about the LibreOffice mailing list