From 3e7a6ff8c32e7fd5947b344e9d22ef7ba48dcca5 Mon Sep 17 00:00:00 2001 From: Ashod Nakashian Date: Mon, 2 Feb 2015 13:53:32 -0500 Subject: 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 Reviewed-by: Noel Grandin --- dtrans/source/win32/dtobj/DataFmtTransl.cxx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dtrans/source/win32/dtobj/DataFmtTransl.cxx b/dtrans/source/win32/dtobj/DataFmtTransl.cxx index 37c8dd86e746..33c458f0bff2 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(wBuff), MAX_CLIPFORMAT_NAME ); return OUString( wBuff, nLen ); -- cgit