confusing use of 'OpCode' in formula/source/core/api/FormulaCompiler.cxx

Winfried Donkers Winfried.Donkers at dekimo.com
Tue Apr 30 09:43:09 UTC 2019


Hi,

I stumbled over an inconsistency in the use of opcodes in formula/source/core/api/FormulaCompiler.cxx: in two locations SC_OPCODE_xxx is used for functions, whereas in all other code (apart from the definitions,  formula/inc/core_resource.hrc, sc/inc/scfuncs.hrc and sc/source/core/data/funcdesc.cxx) ocXxx is used. (It took me hours with gdb to find out why ocIf was handled differenty than ocIfs_MS when the latter was changed to a fump function).

I want to replace the use of SC_OPCODE_XXX in formula/source/core/api/FormulaCompiler.cxx with ocXxx.
In sc/source/core/data/funcdesc.cxx the situation is the other way round, SC_OPCODE_XXX is consequently used for functions and ocXxx is use for oSep, ocOpen and similar. I want to change that too to get a consistent use of opcode names.

So far, no real problems.
But when looking into formula/source/core/api/FormulaCompiler.cxx I noticed that the term 'OpCode' seems to be used both for
type  e.g. line 58:SvNumFormatType lcl_GetRetFormat( OpCode eOpCode ),
members e.g. line 127 aEntry.Token.OpCode = nOpCode; and
variables e.g. line 184: xMap->putOpCode( aOpStr, OpCode(i), pCharClass); .

And as type for opcodes both OpCode (e.g. line 58) and sal_UInt16 (e.g. line 173) are used. OpCode cannot be used in the case of SC_OPCODE_START_UN_OP and the like, but
changing
static const sal_UInt16 aOpCodes[] = {
    SC_OPCODE_OPEN,
    SC_OPCODE_CLOSE,
    SC_OPCODE_SEP,
};
to
static const OpCode aOpCodes[] = {
    SC_OPCODE_OPEN,
    SC_OPCODE_CLOSE,
    SC_OPCODE_SEP,
};
produces compiler errors ('invalid conversion from int to OpCode' and 'invalid conversion from const OpCode to sal_UInt16').

I am confused by this (non) use of 'OpCode'.
Anyone who knows the why and how of this?

Winfried

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20190430/51265355/attachment.html>


More information about the LibreOffice mailing list