Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign

a bug in the expression solver (handling conditional preprocessor directive)

(1/1)

ollydbg:
the code has some bug, see below:

plugins\codecompletion\parser\expression.cpp


--- Code: ---long ExpressionNode::GetNodeTypePriority(ExpressionNodeType type)
{
    switch (type)
    {
    case LParenthesis:
    case RParenthesis:
        return 9;
    case Not:
        return 8;
    case Mod:
        return 7;
    case MultiPly:
    case Divide:
    case Power:
        return 6;
    case Plus:
    case Subtract:
        return 5;
    case LShift:
    case RShift:
        return 4;
    case BitwiseAnd:
    case BitwiseOr:
        return 3;
    case Equal:
    case Unequal:
    case GT:
    case LT:
    case GTOrEqual:
    case LTOrEqual:
        return 2;
    case And:
    case Or:
        return 1;
    default:
        return 0;
    }
}
--- End code ---

The "And" and "Or" should have different precedence.

see:
http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B

BTW, I'm implementing some similar code (I think it was much simpler, in my quex parser tester)
see:
Yesterday, I have implement a quite simple expression parser by shunting yard algorithm combined with Quex lexer. it was very much like the yacc calculator in the demo folders.
The source code was:
http://code.google.com/p/quexparser/source/browse/trunk/cppparser/expression_eval.cpp
http://code.google.com/p/quexparser/source/browse/trunk/cppparser/expression_main.cpp

and the reference was:
http://en.literateprograms.org/Shunting_yard_algorithm_%28C%29

ollydbg:
seems no one was interested on this issue.... :(

Here is the test code to produce this issue:


--- Code: ---#if 1 || 1 && 0
int main();
#endif

--- End code ---

Now, the cc will skip the "main" function.
But the conditional expression value is "true".

MortenMacFly:

--- Quote from: ollydbg on January 05, 2011, 02:01:50 am ---seems no one was interested on this issue.... :(

--- End quote ---
I guess it's Loaden who should give a statement. It seems you are right, obviously.

Loaden:

--- Quote from: MortenMacFly on January 05, 2011, 06:57:18 am ---
--- Quote from: ollydbg on January 05, 2011, 02:01:50 am ---seems no one was interested on this issue.... :(

--- End quote ---
I guess it's Loaden who should give a statement. It seems you are right, obviously.

--- End quote ---
Fixed in rev6983.

ollydbg:
Nice work! loaden
I'm currently testing a same shunting yard algorithm(directly infix expression, avoid the postfix generation).
see:
http://code.google.com/p/quexparser/source/browse/trunk/cppparser/ConstExpression.h
and
http://code.google.com/p/quexparser/source/browse/trunk/cppparser/ConstExpression.cpp

I think you don't need to generate a postfix, then calculate the postfix again.
I think you can avoid the "generate a postfix" stage, and calculate the value directly. you can see my code, it will be more faster.

Navigation

[0] Message Index