[Libreoffice] revert incorrectl RTL_CONSTASCII_ usage ...

Thomas Arnhold thomas at arnhold.org
Fri Jan 28 10:29:58 PST 2011


Yes, sorry for that ;)

On 01/28/2011 06:03 PM, Michael Meeks wrote:
> Hi there,
> 
> 	I just had to revert:
> 
>     Replace suitable equalsAscii calls with equalsAsciiL.
> 
> diff --git a/oox/source/ole/axbinaryreader.cxx b/oox/source/ole/axbinaryreader.cxx
> index 36cc2d7..105db2b 100644
> --- a/oox/source/ole/axbinaryreader.cxx
> +++ b/oox/source/ole/axbinaryreader.cxx
> @@ -150,7 +150,7 @@ bool AxFontData::importGuidAndFont( BinaryInputStream& rInStrm )
>      OUString aGuid = OleHelper::importGuid( rInStrm );
>      if( aGuid.equalsAsciiL( RTL_CONSTASCII_STRINGPARAM( "{AFC20920-DA4E-11CE-B943-00AA006887B4}" ) ) )
>          return importBinaryModel( rInStrm );
> -    if( aGuid.equalsAscii( OLE_GUID_STDFONT ) )
> +    if( aGuid.equalsAsciiL( RTL_CONSTASCII_STRINGPARAM( OLE_GUID_STDFONT ) ) )
>          return importStdFont( rInStrm );
>      return false;
>  }
> 
> 	This sort of thing.
> 
> 	The code is not correct; OLE_GUID_STDFONT is a const sal_Char * pointer
> - so when we start doing sizeof() on it to detect the string length it
> gets a -very- wrong (and dangerous) value. Luckily Caolans' sal patch
> breaks the build if you have a recent enough compiler for this. Of
> course; quite -why- it is a const sal_Char * I have no idea - it betrays
> a lack of faith in the compiler's ability to optimise duplicate string
> instances I suspect - prolly worth auditing their use, and fixing that
> too. There was some madness before about sharing the same string
> instance across modules via. a symbol which just burns space vs. having
> it duplicated in two libraries; we should prolly undo that and just use
> some defines.
> 
> 	I thought we had ~nearly finished this hack - of fixing up all the
> equalsAscii's that can be safely done :-)
> 
> 	Thanks,
> 
> 		Michael.
> 



More information about the LibreOffice mailing list