[Libreoffice-commits] core.git: dtrans/source

[Ashod Nakashian]

 dtrans/source/win32/dtobj/DataFmtTransl.cxx |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit 3e7a6ff8c32e7fd5947b344e9d22ef7ba48dcca5
Author: Ashod Nakashian <ashodnakashian at 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 <ci at libreoffice.org>
    Reviewed-by: Noel Grandin <noelgrandin at 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 );