dtrans/source/win32/dtobj/DataFmtTransl.cxx | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
New commits:
commit 3e7a6ff8c32e7fd5947b344e9d22ef7ba48dcca5
Author: Ashod Nakashian <ashodnakash...@yahoo.com>
Date: Mon Feb 2 13:53:32 2015 -0500
Fix for possible unaddressable write.
DrMemory reports unaddressable write of 2 bytes (a single unicode character)
in GetClipboardFormatNameW.
While the API documentation do not imply that the buffer length excludes
the null terminator, the returned length does.
Even though in my case the format name was "HTML Format" which is
far shorter than the 256 character buffer size, DrMemory consistently
cought unaddressable write at the end of the buffer.
It's not clear why GetClipboardFormatNameW would need to access
beyond the length of the data it writes, but this fix is harmless
and at least will silence DrMemory, if not fix a genuine issue.
Change-Id: Ib8ac69a65d4fcff53e71f56f9a06c9c7299be1ba
Reviewed-on: https://gerrit.libreoffice.org/14286
Tested-by: Jenkins <c...@libreoffice.org>
Reviewed-by: Noel Grandin <noelgran...@gmail.com>
diff --git a/dtrans/source/win32/dtobj/DataFmtTransl.cxx
b/dtrans/source/win32/dtobj/DataFmtTransl.cxx
index 37c8dd8..33c458f 100644
--- a/dtrans/source/win32/dtobj/DataFmtTransl.cxx
+++ b/dtrans/source/win32/dtobj/DataFmtTransl.cxx
@@ -170,7 +170,7 @@ OUString CDataFormatTranslator::getClipboardFormatName(
CLIPFORMAT aClipformat )
{
OSL_PRECOND( CF_INVALID != aClipformat, "Invalid clipboard format" );
- sal_Unicode wBuff[ MAX_CLIPFORMAT_NAME ];
+ sal_Unicode wBuff[ MAX_CLIPFORMAT_NAME + 1 ]; // Null terminator isn't
counted, apparently.
sal_Int32 nLen = GetClipboardFormatNameW( aClipformat,
reinterpret_cast<LPWSTR>(wBuff), MAX_CLIPFORMAT_NAME );
return OUString( wBuff, nLen );
_______________________________________________
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
