Run scanbuild with asserts enabled, as suggested by its manual

[Voker57]

No description provided.

[afwbkbc]

I don't think it's good idea, it's more important to check Release because that's what most (or all) players will use.
In some cases something may work in debug because of ASSERT, while in Release it may produce silent bugs, this should be checked

[Voker57]

I don't think it's good idea, it's more important to check Release because that's what most (or all) players will use. In some cases something may work in debug because of ASSERT, while in Release it may produce silent bugs, this should be checked

can do both, but debug is more important for static analysis as it includes more code and enables assertions which help to analyze the code.

[afwbkbc]

'both' would make builds even slower than it is now.
Debug builds may include more code but that extra code won't be used by actual players, also it's a bit different from release so something may be broken in release but not debug (in this case analyzer won't find it if it will test debug). Debug builds can also have some ifdefs with quick hacks to test something that analyzer will go crazy about (and I don't feel like polishing debug builds to keep analyzer happy 24/7)

[Voker57]

Changed the PR to instead enable asserts for more accurate analysis.

[afwbkbc]

Have you checked that force-analyze-debug-code actually does anything?
In GLSMAC asserts are not normal C++ asserts, but

#if defined( DEBUG ) || defined( FASTDEBUG )

#define ASSERT( _condition, _text ) \
    if ( !( _condition ) ) { \
        Log( (std::string) "FATAL: " + _text ); \
        THROW( _text ); \
    }

// for rare cases when Log() is not available
#define ASSERT_NOLOG( _condition, _text ) \
    if ( !( _condition ) ) { \
        THROW( _text ); \
    }

#else
#define ASSERT( _condition, _text )
#define ASSERT_NOLOG( _condition, _text )
#endif

meaning they are removed in Release during preprocessing.

I checked and haven't found any good justification of scanning in debug mode instead of release.
There is:

2.2.2.8. Always Analyze a Project in its “Debug” Configuration

Most projects can be built in a “debug” mode that enables assertions. Assertions are picked up by the static analyzer to prune infeasible paths, which in some cases can greatly reduce the number of false positives (bogus error reports) emitted by the tool.

which gives no reasons and then just explains how to deal with problems of scanning debug builds (false positives).

[Voker57]

Perhaps use normal assertions instead of your bikeshed stuff then? No idea if it does.