tdf#133077: fix lone CR handling in plain text clipboard on Windows
Failing to treat CRs without corresponding LFs resulted in 0 inserted
in the place of the CR, but the text up to this position not inserted,
and pLastStt not updated. Thus all following text was dropped when the
insertion was finally performed (when CRLF or EOF was reached), because
of the 0 marking end of inserted text. But that was inconsistent with
how other Windows applications treated stand-alone CRs, and also with
our own handling of them when they happened in the end of the internal
read buffer.
Change-Id: Idf4876b0cccd4aa3f14f6efede54d27670f55c35
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94277
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
diff --git a/sw/source/filter/ascii/parasc.cxx b/sw/source/filter/ascii/parasc.cxx
index 5bc3999..2cf851d 100644
--- a/sw/source/filter/ascii/parasc.cxx
+++ b/sw/source/filter/ascii/parasc.cxx
@@ -401,19 +401,17 @@ ErrCode SwASCIIParser::ReadChars()
*pStt = 0;
++pStt;
bool bChkSplit = false;
bool bChkSplit = true;
if( LINEEND_CRLF == pUseMe->GetParaFlags() )
{
if( pStt == pEnd )
cLastCR = 0x0d;
else if( 0x0a == *pStt )
{
++pStt;
bChkSplit = true;
cLastCR = 0x0d;
bChkSplit = false;
}
else if( 0x0a == *pStt )
++pStt;
}
else
bChkSplit = true;
// We skip the last one at the end
if( bChkSplit && ( !rInput.eof() || pEnd != pStt ))
