How to handle the precedence in this case in Flex/Bison

I'm doing something work to parse the internal configuration files in our project. The configurations can be a simple string or a "function" that we created for internal use. The function can take string type argument and a special type representing the "condition". Part of my flex token file looks like this:

[a-zA-Z][a-zA-Z0-9_/=\.]*   SAVE_TOKEN; return TSTRING;
"("                         SAVE_TOKEN; return TLPAREN;
")"                         SAVE_TOKEN; return TRPAREN;
","                         SAVE_TOKEN; return TCOMMA;
"=="                        SAVE_TOKEN; return TIFEQUAL;
"!="                        SAVE_TOKEN; return TIFNEQUAL;

Part of my bison parser file looks like this:

condition: expr TIFEQUAL expr { $$ = new NCondition($1, TIFEQUAL, $3);}
          |expr TIFNEQUAL expr { $$ = new NCondition($1, TIFNEQUAL, $3);}
          ;
sring:     TSTRING { $$ = new NString(*$1); }
          ;
expr:     string {$<nstring>$ = $1;}
        | string TLPAREN call_args TRPAREN { $$ = new NFunction($1, *$3); }
        ;
call_args: { $$ = new CallArg(); }
        |  expr { $$ = new CallArg(); }
        |  call_args TCOMMA condition { $1->conds.push_back($3); }
        |  call_args TCOMMA expr   { $1->exprs.push_back($3); }
        ;

Here the conflict is, a string type allows euqal sign "=", which is also part of the token TIFEQUA. Consider a function like this:

function(arg1, arg2, arg_cond==condition)

Parser will try to match the TSTRING token rather than TIFEQUAL. I did some research and I realized that flex is greedy and will try to match the longest one if two patterns both match. Does that mean my conflist has to be resolved at bison level? If yes, how should I handle this case?

This is due to the lex recognizer always recognizing the longest possible token in the input stream (as you note), and can only be "fixed" by changing your lex patterns. There's nothing you can do in bison as by then it is too late -- the string has already been recognized as a single TSTRING token.

One obious possibility is to remove the = from the TSTRING pattern as that is normally not a legal token in a name/identifier. If you really want to allow some = in them, you need to decide exactly when they should be part of a TSTRING vs a separate operator. You could disallow two consecutive = or an = at the end of the TSTRING:

[a-zA-Z](=?[a-zA-Z0-9_/\.])*     SAVE_TOKEN; return TSTRING;

which would cause your input of arg_cond==condition to be recognized as 3 tokens instead of 1. However, then something like a==b==c would result in a syntax error when in theory it could be recognized as a==b == c or a == b==c -- but which it should be is not clear.