this story started in
    commit  433fc221 (patch)
    sal_uIntPtr->sal_Int32 in MultiSelection
which caused a regression, reported in tdf#116981.
I attempted to fix it in
    commit 235d61890512894e27f4f81e38a325eee3c67b30
    Date:   Fri Apr 13 17:14:59 2018 +0200
    tdf#116981 Base when deleting table column
and
    commit 0973e1f4
    Date:   Mon Apr 16 08:28:16 2018 +0200
    follow on for tdf#116981

But my analysis was wrong.

To recap, and get it right:

Before all this, MultiSelection stored it's values internally as
sal_uIntPtr, but returned them as long in FirstSelected(),
NextSelected(),and SFX_ENDOFSELECTION was defined to be ULONG_MAX.
On 64-bit Linux, sal_uIntPtr is typedefed to sal_uInt64, and ULONG_MAX
is 2^64, which means that previously, the SFX_ENDOFSELECTION value was
being converted from 2^64 to -1 when it was returned, which was why
these loops worked.

So convert SFX_ENDOFSELECTION to -1 to match how how the external code
wants it to be (and the code frequently uses -1 instead of
SFX_ENDOFSELECTION or BROWSER_ENDOFSELECTION)

The modification to MultiSelection::Select is necessary because
previously, nCurMin and nCurMax would be == ULONG_MAX,
and we would, somewhat unintuitively, end up in the
    // expand on left side?
    if( nTmpMax < nCurMin )
part of the logic, which would do the right thing, even if a little
weirdly.

Change-Id: I7c830b0392add394d8c294247f75a2ffe8017c24
Reviewed-on: https://gerrit.libreoffice.org/53022Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>