On 08/29/2012 09:06 PM, Libreoffice Gerrit user wrote:
commit ecfa813595cb577781668219d9e17a0494f92bea
Author: Zolnai Tamás <[email protected]>
Date: Wed Aug 29 12:58:29 2012 +0200
Some cleanup
Use normal integer types when it's unecessary to use
sal_int types.
Delete some hack from code.
Change-Id: I93f0b1f260578d3aa9609b7e9d8a79053693971b
Reviewed-on: https://gerrit.libreoffice.org/510
Reviewed-by: Andras Timar <[email protected]>
Tested-by: Andras Timar <[email protected]>
[...]
diff --git a/l10ntools/source/po.cxx b/l10ntools/source/po.cxx
index c488c87..472e876 100644
--- a/l10ntools/source/po.cxx
+++ b/l10ntools/source/po.cxx
@@ -59,10 +59,10 @@ OString ImplEscapeText(const OString& rText,
{
if(rEscaped.getLength()!=2*rUnEscaped.getLength()) throw;
OString sResult = rText;
- sal_Int32 nCount = 0;
- for(sal_Int32 nIndex=0; nIndex<rText.getLength(); ++nIndex)
+ int nCount = 0;
+ for(int nIndex=0; nIndex<rText.getLength(); ++nIndex)
{
- sal_Int32 nActChar = rUnEscaped.indexOf(rText[nIndex]);
+ int nActChar = rUnEscaped.indexOf(rText[nIndex]);
if(nActChar!=-1)
sResult = sResult.replaceAt((nIndex)+(nCount++),1,
rEscaped.copy(2*nActChar,2));
What's the reason for changes like this? The involved type is
sal_Int32, not int, and sal_Int32 is not necessarily a typedef for int
(e.g., it is a typedef for long on some platforms). I fear that
routinely using plain int instead of those sal types when interfacing
with code using those sal types leads to unnecessary compiler warnings.
Stephan
_______________________________________________
LibreOffice mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
