Complete the transition of SwRedlineTable::size_type

...from 9ca8a63fff65acf2ea13b391495ad232f4636548 "Use consistent integer types
in the SwRedlineTable interface".  This all started as an attempt to reduce the
number of places a to-be-committed improved loplugin:loopvartoosmall complains
about.  Lets see where it ends...

SwRedlineTable::size_type is now the size_type of the underlying std::vector, no
longer sal_uInt16 from ancient times.  I tried hard to find all places that are
affected by this change, changing types of affected variables and non-static
data members as needed.  Some notes:

* The original code used USHRT_MAX as a "not found" value.  I replaced that with
a new SwRedlineTable::npos, of type SwRedlineTable::size_type but still for
now of value USHRT_MAX.  This should eventually be changed to something more
sensible, like std::numeric_limits<SwRedlineTable::size_type>::max() (which is
best done after we have constexpr support in all toolchains, so that npos can
be constexpr).  It is important that the value of npos is towards positive
infinity, as many places in the code use

for (i = f(); // may return npos
i < table.size(); ++i)
table[i] ...

* There are some borders where values of SwRedlineTable::size_type are converted
into different types, for various reasons.  But all of those other types
should be large enough for practical purposes (at least 32 bits wide):

MakrEntry::m_nIdx: long int
SvxRedlinTable::InsertEntry: sal_uIntPtr nPos
SwRangeRedline: size_t
SwRedlineItr: sal_Int32
SwVbaRevision::GetPosition: sal_Int32
SwXRedlines: sal_Int32

* .uno:TrackedChangeIndex= transports textual representations of such values.
libreofficekit/qa/gtktiledviewer/gtktiledviewer.cxx treats them purely as
strings, while SwTiledRenderingTest converts them to int.

* TODO:  The one place I'm unsure about is SfxUInt16Items with IDs
FN_REDLINE_ACCEPT_DIRECT, FN_REDLINE_REJECT_DIRECT, and FN_REDLINE_NEXT_CHANGE
in sw/source/uibase/uiview/view2.cxx.  For now, I kept those as
SfxUInt16Items and take care to "map" USHRT_MAX to npos when reading from
those items.  But I have no idea where instances of those items would actually
be created, and what it would mean to change those items' types?

Change-Id: Ib7a14dc67e2b970766966e43f4732abd9f045ff8
Reviewed-on: https://gerrit.libreoffice.org/34775
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

0 files changed, 0 insertions, 0 deletions