should there really be duplicateAssignExpression warnings when assigning constant values?

[Daniel Marjamäki]

Cppcheck writes duplicateAssignExpression warnings for constant values..

In hexxagon there is this code and cppcheck warns that best and alpha are assigned with the same expression:

bool libhexx::scoreMoves(std::vector<Move> &moves, const Board board, const LookUp& lookUp, int depth, bool (*callback)(), int maxtime)
{
    time_t t = time(NULL);

    for(int i = 1; (i < depth) && (time(NULL) - t <= maxtime); i++)
    {
        int best  = -SCR_INFINITY; // <---- CPPCHECK WARNING
        int alpha = -SCR_INFINITY;
        int beta  = SCR_INFINITY;

        for(std::vector<Move>::iterator j = moves.begin(); (j != moves.end()) && (time(NULL) - t <= maxtime) && (best < beta); j++)
        {
            if(best > alpha)
                alpha = best;

            Board newboard = Board(board);
            newboard.applyMove(*j, lookUp);
            int value = -alphaBeta(newboard, lookUp, false, i, -beta, -alpha, callback);

            if(value == SCR_BREAK)
                return false;

            j->score = value;

            if(value > best)
                best = value;
        }

        stable_sort(moves.rbegin(), moves.rend());
    }

    return true;
}

The warning is "inconclusive".. but well I feel that such code looks reasonable to me.

SCR_INFINITY is a enum constant.

[Paul Fultz]

We can remove the inconclusive, but I think we should add a flag to enable more aggressive copy-paste detection, since --inconclusive doesn't seem to be the right flag.

[Daniel Marjamäki]

enable more aggressive copy-paste detection

sounds ok to me.

If there will be a reasonable amount of noise, I do believe you should use --inconclusive anyway. But if there will typically be 100s of warnings in normal well written projects then I suggest that such copy/paste detection is put in an addon.

[Daniel Marjamäki]

then I suggest that such copy/paste detection is put in an addon.

however I assume you want to reuse followVar?

hmm.. that can't easily be done in a addon. At least not right now.

[Paul Fultz]

hmm.. that can't easily be done in a addon. At least not right now.

Yea, cppcheck should add a python API. Its fairly easy to do with pybind11.

[Daniel Marjamäki]

I assume that api will mean that the python scripts that use that must use LGPL compatible license? So it will not be possible to write a commercial addon. I'm not sure if that matters just want to understand the limit..

[Paul Fultz]

I assume that api will mean that the python scripts that use that must use LGPL compatible license?

I don't think that would be considered a derivative work since its not statically linked nor includes any cppcheck sources, but I am not a lawyer.

I'm not sure if that matters just want to understand the limit..

It also may not matter since I dont see how its possible to write a python addon without having the source code available.