Caolán McNamara caolanm at redhat.com
Sun Nov 14 04:47:00 PST 2010

Michael mentioned to me that he had seen cases where
"RTL_CONSTASCII_STRINGPARAM" was accidentally used instead of

#define RTL_CONSTASCII_STRINGPARAM( constAsciiStr ) constAsciiStr,

#define RTL_CONSTASCII_USTRINGPARAM( constAsciiStr ) constAsciiStr,
((sal_Int32)(sizeof(constAsciiStr)-1)), RTL_TEXTENCODING_ASCII_US

The problem arises when someone is using the old "String" class because
it has a load of constructors, two of which are...

UniString( const sal_Char* pByteStr, rtl_TextEncoding eTextEncoding,


UniString( const sal_Char* pByteStr, xub_StrLen nLen, rtl_TextEncoding
eTextEncoding, sal_uInt32 nCvtFlags =

So if someone uses RTL_CONSTASCII_USTRINGPARAM the right thing happens
and the better fitting second ctor is selected, char*, len, encoding all
filled in correctly.

On the other hand if someone uses RTL_CONSTASCII_STRINGPARAM, then the
better fitting first ctor is selected and the *ENCODING* argument is
filled in with the length of the string. Puke.

I should note that none of these errors are new or have been introduced
recently, but have been lurking in the code for quite a while.

Attached is a patch to the class String class which adds a higher
constructor that exactly matches the output of
RTL_CONSTASCII_STRINGPARAM but marks it private, detecting this misuse
at compile time, which should make this impossible to happen again, but
retain any correct uses of the first constructor where a real 16bit
rtl_TextEncoding is used, and not an implicitly downcasted sal_Int32.

I've already found quite a few problems with this, so once I complete a
build and fixed the detected misuses I'll stick this in.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tools.detectwrongmacro.patch
Type: text/x-patch
Size: 618 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20101114/be94dd1d/attachment.bin>

More information about the LibreOffice mailing list