threadsafety-unsafe-call false positive

[Nikita Leontiev]

cppcheck 2.18.0 generates threadsafety-unsafe-call false positive for the following code:

struct Object
{
    int ctime;
};

int main()
{
    Object obj;
    obj.ctime = 0;
    return 0;
}

test\main.cpp:3:6: warning: ctime is MT-unsafe [threadsafety-unsafe-call]
 int ctime;
     ^
test\main.cpp:9:6: warning: ctime is MT-unsafe [threadsafety-unsafe-call]
 obj.ctime = 0;
     ^

[CHR]

threadsafety-unsafe-call seems to be a cppcheck Premium feature, so you should report the bug here: https://www.cppcheck.com/

[Nikita Leontiev]

I used open source cppcheck 2.18.0 with --addon=threadsafety.py arg.

[CHR]

I see, didn't realize that this addon existed.

[Andrew C Aitchison]

On Ubuntu 25-04 (Plucky) man ctime says (in the attributes table):

Interface	Attribute	Value
ctime()	Thread safety	MT-Unsafe race:tmbuf race:asctime env locale

(see man 7 attributes for the detaiila of the terms used).

so this is an edge case, but it is not obvious to me that it is a false-positive - what do others think ?

Background

The list of MT-unsafe functions in the threadsafety addon is computer-generated by tools/MT-Unsafe.py which reads the attributes table of man pages. We could ignore race conditions highlighted in this table if you think these are false positives, or we could specifically exclude ctime().
Bear in mind that a function can could be thread safe on one platform but unsafe on another and may change over time eg man strerror on my machines says:
Before glibc 2.32, strerror() is not MT-Safe.
https://sourceforge.net/p/cppcheck/discussion/general/thread/209919289c/

[CHR]

The original code does not reference ctime() at all.

[Andrew C Aitchison]

In that case it is definitely a bug in addons/threadsafety.py
I note that
cppcheck --enable=warning --addon=y2038.py test/main.c
gives similar false positives.

I copied this feature from y2038.py to threadsafety.py but I don't think my python is up to fixing this.