sdext/source/pdfimport/tree/imagecontainer.cxx | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
New commits:
commit 59ac648a1482d9422b8f279bcb284a214032f5cf
Author: Stephan Bergmann <sberg...@redhat.com>
AuthorDate: Thu Feb 17 12:07:48 2022 +0100
Commit: Stephan Bergmann <sberg...@redhat.com>
CommitDate: Thu Feb 17 13:23:56 2022 +0100
Parameter should apparently be of type sal_Int32
It was like this ever since 969aac0edf437ec0cad0baadfde46188c4822161
"INTEGRATION: CWS pdf25", but the single caller of encodeBase64 passes a
sal_Int32 value, and all use of i_nBufferLength in encodeBase64 are in
sal_Int32-based computations.
Change-Id: I2963a05bf5a83aaee25cdd71c11d28481b28061a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130067
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sberg...@redhat.com>
diff --git a/sdext/source/pdfimport/tree/imagecontainer.cxx
b/sdext/source/pdfimport/tree/imagecontainer.cxx
index bedbcd73b020..9754e9134a50 100644
--- a/sdext/source/pdfimport/tree/imagecontainer.cxx
+++ b/sdext/source/pdfimport/tree/imagecontainer.cxx
@@ -43,7 +43,7 @@ const char aBase64EncodeTable[] =
'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z',
'0', '1', '2', '3', '4', '5', '6', '7', '8', '9', '+', '/' };
-OUString encodeBase64( const sal_Int8* i_pBuffer, const sal_uInt32
i_nBufferLength )
+OUString encodeBase64( const sal_Int8* i_pBuffer, const sal_Int32
i_nBufferLength )
{
OUStringBuffer aBuf( (i_nBufferLength+1) * 4 / 3 );
const sal_Int32 nRemain(i_nBufferLength%3);
