uninitMemberVar false positive

[Dmitry Kuteynikov]

CppCheck complains about METHOD being uninitialized variable in templated class instantiated for int128.
Probably due to overall lack of int128 support.

[Daniel Marjamäki]

Thanks for reporting.. could you create a minimal example that reproduce the FP?

[Dmitry Kuteynikov]

It's a part of big project. I tried just now to cut out the part in question and did not succeed: it's either too big to be easily understanded (and it's commercial project, so I simply can't put it all here) or cppcheck finds no error.
The offending item is some custom hashtable that is developed specifically to work with large integers (64/128 bit) and as so is templated by used type. It's marked in header for intantiation as

extern template class HashTableInteger<int64_t>;
extern template class HashTableInteger<uint64_t>;
extern template class HashTableInteger<int128_t>;
extern template class HashTableInteger<uint128_t>;

and later in code after class definition as

template class HashTableInteger<int64_t>;
template class HashTableInteger<uint64_t>;
template class HashTableInteger<int128_t>;
template class HashTableInteger<uint128_t>;

the usual thing with splitting templated class declaration/definition to avoid excess compilation and keep header short and neat.

The method in question is protected method that gets templated type value as one of the arguments.
I do believe the main reason behind ths FP is general lack of support for int128 in cppcheck - I posted here some time ago it's complains about shifting 128-bit value by more than 32 bits being an error. The fact that cppcheck doesn't complains about any other instantation of same hashtable support this assumption quite well in my eyes (just tried 8/16/32-bit versions too, just to be sure).
I'll try to make smallest possible example, however, I keep my hopes low at the moment... :-(

[Daniel Marjamäki]

that is usually the case. there is some more detail somewhere that is confusing cppcheck somehow. very hard to guess.

I suggest that you take your commercial code. then step by step remove various blocks of code. includes, classes, functions, .. as long as you can still reproduce the FP continue.

[Dmitry Kuteynikov]

That's exactly what I'm doing at the moment. The problem is, I don't have much free time for this. I'll definitely try my best, though.

[Dmitry Kuteynikov]

Ok. I did it. It compiles and cppcheck says bad words. Took quite a few attempts.
There are two pair of files besides CMakeLists.txt.
HashTable - support stuff that doesn't really matters, most everything cut out anyway.
HashTableInteger - the templated class in question, whose methods are FP-ed as uninitialized variables.

Just in case: Cppcheck 1.90

[CHR]

Further reduced example:

__extension__ using uint128_t = unsigned __int128;
__extension__ using int128_t = __int128;

template <typename T>
class HashTableInteger
{
public:
    explicit HashTableInteger(DataStore &&uniqs, const size_t offset, const size_t min_capacity);
    ~HashTableInteger() = default;

    bool insert_old(T value, uint32_t num);
};

template <typename T>
HashTableInteger<T>::HashTableInteger(DataStore &&uniqs,
                                      const size_t offset,
                                      const size_t min_capacity)

{
}

template class HashTableInteger<int128_t>;
template class HashTableInteger<uint128_t>;

What is the value of the __extension__ macro? It seems that cppcheck does not know about it.
Just a tip: when reducing code, it does not matter if it still compiles, as long as cppcheck accepts it and still reproduces the error.

[Dmitry Kuteynikov]

It's recommended way to mark custom gcc types like __int128 so gcc -Wpedantic won't complain that they're not ISO.
My attempts on reducing example in mostly same way resulted in no complains from cppcheck... That's my luck... ;-)

[CHR]

Maybe __extension__ should be part of some .cfg configuration/platform then? At least passing -D__extension__ to cppcheck fixes the error message for me.

[Daniel Marjamäki]

Try to add --library=gnu to your command line then __extension__ should be handled.

[Dmitry Kuteynikov]

@CHR, @Daniel Marjamäki - many thanks!
Both your solutions works (the define and the library specification). This doesn't resolve some other issues with int128, namely bit shifts, but "this is another story".
Thanks a lot!