tdf#144106 Don't proceed ptrim_i past ptrim_f

...which would cause p2 - p1 to be negative in lcl_appendLineData and thus
construction of a std::u16string_view with a huge positive length of type
size_t.  In 64-bit builds where size_t is 64-bit, that would then cause
termination due to an uncaught std::bad_alloc.  But in (implicitly)
--disable-assert-always-abort 32-bit builds where size_t is 32-bit, this would
silently have worked before 1efec9ec21dba32335e311d367b636538e219621 "Tighten
rtl_{string,uString}_newFromStr_WithLength implementation", when the huge
positive size_t value was cast back to a negative sal_Int32 that was gracefully
handled by rtl_uString_newFromStr_WithLength.

Change-Id: I3b95a9fce62b99ffc150f76a1c6ccddcdacdae0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122038
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(cherry picked from commit 4a4be7a1edead11b48e1a8598e52a3246e6744bb)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122064
Reviewed-by: Caolán McNamara <caolanm@redhat.com>

1 files changed, 1 insertions, 1 deletions

diff --git a/sc/source/ui/docshell/impex.cxx b/sc/source/ui/docshell/impex.cxx
index f271a70feee9..875f051174d9 100644
--- a/sc/source/ui/docshell/impex.cxx
+++ b/sc/source/ui/docshell/impex.cxx
@@ -1688,7 +1688,7 @@ const sal_Unicode* ScImportExport::ScanNextFieldFromString( const sal_Unicode* p
         const sal_Unicode* ptrim_f = p;  // [ptrim_i,ptrim_f) is cell data after trimming
         if ( bRemoveSpace )
         {
-            while ( *ptrim_i == cBlank )
+            while ( ptrim_i < ptrim_f && *ptrim_i == cBlank )
                 ++ptrim_i;
             while ( ptrim_f > ptrim_i && ( *(ptrim_f - 1) == cBlank ) )
                 --ptrim_f;