Re: [Libreoffice-commits] core.git: formula/source: get rid of unnecessary warning

Hi Eike,

Op 27-08-13 16:20, Eike Rathke wrote:
> Hi Winfried,
>
> On Tuesday, 2013-08-27 06:48:28 -0700, Winfried Donkers wrote:
>
> > commit e5321437322fd812b93fee266af309e782479488
> > Author: Winfried Donkers <winfrieddonkers@libreoffice.org>
> > Date:   Thu Aug 22 17:03:58 2013 +0200
> >
> >      get rid of unnecessary warning
> >      
> >      A value of 0 for Opcode eOp produces a debug assertion that is
> >      not in place as opcode with value does exist (ocPush, SC_OPCODE_PUSH).
> >
> > --- a/formula/source/core/api/FormulaCompiler.cxx
> > +++ b/formula/source/core/api/FormulaCompiler.cxx
> > @@ -488,8 +488,8 @@ uno::Sequence< sheet::FormulaOpCodeMapEntry > FormulaCompiler::OpCodeMap::create
> >   
> >   void FormulaCompiler::OpCodeMap::putOpCode( const String & rStr, const OpCode eOp )
> >   {
> > -    DBG_ASSERT( 0 < eOp && sal_uInt16(eOp) < mnSymbols, "OpCodeMap::putOpCode: OpCode out of 
> > range");
> > -    if (0 < eOp && sal_uInt16(eOp) < mnSymbols)
> > +    DBG_ASSERT( sal_uInt16(eOp) < mnSymbols, "OpCodeMap::putOpCode: OpCode out of range");
> > +    if (sal_uInt16(eOp) < mnSymbols)
> >       {
> When did you encounter that warning?
> Putting ocPush into an OpCodeMap probably indicates an error, as ocPush
> is not an operator or function that maps to any string. An ocPush is
> always used with a cell reference, fixed value or function result.
> Unless there is a compelling reason for this change I suggest to revert it.
That warning occurred e.g. on start up of calc. 
FormulaCompiler::OpCodeMap::putOpCode() is called for opCode 0 and then 
for opCode 6 till 412 (as the warning ' reusing opCode'  occurs as many 
times).
As in FormulaCompiler::String& getSymbol() the DBG_ASSERT is called 
without the 0 < eOp, eOp is unsigned (so the expression is about eOp 
equalling 0 only) and other special commands (opCode 1 till 5) aren' t 
excluded, I thought it safe to remove the 0 < eOp from both lines.

I hope this information helps. If you want to revert the change, it may 
be wise to make the DBG_ASSERT expression in FormulaCompiler::String& 
getSymbol() the same and/or check for all special command opCodes (i.e. 
check for eOp > 5).
And of course, fixing the cause of the call of 
FormulaCompiler::OpCodemap::putOpCode() with eOp 0. ;)

Meanwhile, I keep on digging in add-in functions that always appear with 
local function names (fdo#50118)...

Winfried