New Defects reported by Coverity Scan for LibreOffice

[Caolán McNamara]

On Mon, 2022-02-14 at 08:25 +0100, Luboš Luňák wrote:
> On Saturday 12 of February 2022, scan-admin at coverity.com wrote:
> > /sc/source/core/data/fillinfo.cxx: 253 in
> > <unnamed>::initCellInfo(RowInfo
> > *, unsigned long, short, const SvxShadowItem *)() 247         {
> > 248             RowInfo& rThisRowInfo = pRowInfo[nArrRow];
> > 249             rThisRowInfo.allocCellInfo( nRotMax + 1 );
> > 250
> > 251             for (SCCOL nCol = -1; nCol <= nRotMax+1; ++nCol) //
> > Preassign cell info 252             {
> > 
> > > > >     CID 1498148:  Integer handling issues  (NEGATIVE_RETURNS)
> > > > >     "nCol" is passed to a parameter that cannot be negative.
> > 
> > 253                 CellInfo& rInfo = rThisRowInfo.cellInfo(nCol);
> 
>  Any idea what this is about? It's RowInfo::cellInfo(SCCOL), and
> SCCOL is sal_Int16, so the parameter can be negative. Does Coverity
> somehow know that SCCOL under normal circumstances should not be
> negative?

Right now the coverity site is down wrt logging in to see the full
details (there's an upgrade scheduled so I presume that's why). Some of
the checkers (like unchecked return) do take into account that
something is checked some X% of the time but I don't think the
NEGATIVE_RETURN is one of those.

My guess is that splitting the assert in cellInfo(SCCOL nCol) to always
check nCol >= -1 regardless of DBG_UTIL would silence it.