HI, I just started to look into MC/DC, and if I understand correctly, with the current implementation, you can have 100% MC/DC coverage in the following case:

In D91000#3862210, @whisperity wrote:

In D91000#3861942, @aaron.ballman wrote:

My concern with that approach was that we pay the full expense of doing the matches only get get into the check() function to bail out on all the Annex K functions, but now that there are replacements outside of Annex K, I don't see a way around paying that expense, so I think my concern has been addressed as well as it could have been.

I think that Clang-Tidy checks are instantiated per AST. I will look into whether we can somehow do the disabling of the check as early as possible! (In that case, we could simply NOT register the matcher related to Annex-K functions.) Either way, I'll do a rebase, re-run the tests and etc., and likely take over the check.

Addressing review comments.

Hi, sorry for the late answer, did not have time to check this in the last few weeks. I will try to address all of the remaining comments.

In D91000#3612090, @Eugene.Zelenko wrote:

Locations for tests and check documentation was changed recently. Please rebase from main and adjust your code accordingly.

updates based on comments.

In D91000#3506605, @whisperity wrote:

Just one question if you could try this out for me: what happens if you run clang-tidy a.c b.c (two TUs in the invocation) where one of them (preferably the later one, i.e. b.c) does NOT have Annex K enabled? I believe the cached IsAnnexKAvailable (like any other TU-specific state of the check instance) should be invalidated/cleared in an overridden void onStartTranslationUnit() function.

Also, what happens if the check is run for C++ code?

Checker has been moved to bugprone.

In D91000#3313892, @balazske wrote:

Now it would be better to have a checker called UnsafeFunctionsCheck (probably in bugprone) and add the cert checkers "msc24-c" and "msc33-c" as aliases. This makes the check extendable if more (CERT rule related or not) cases for unsafe functions are added.

I changed the class name: ObsolescentFunctionsCheck->UnsafeFunctionsCheck.
Since MSC33-C is also included, I changed the checker name to cert-msc24-msc33-c.
I added the following functions from CheckSecuritySyntaxOnly under option 'ReportMoreUnsafeFunctions': bcmp, bcopy, bzero, getpw, vfork. Since there is a replacement suggested there, I added the replacement suggestions also.
I did not add tmpnam, tmpfile, mktemp, mkstemp, rand..() to the checker, because there are separate CERT rules for these.

In D91000#3225369, @balazske wrote:

The functions asctime and asctime_r are discouraged according to CERT MSC33-C rule. These could be added to this check as well. There is a clang SA checker SecuritySyntaxChecker that contains other obsolete functions (and the whole check looks like it can be done in clang-tidy).

Maybe we could remove the check for setbuf() and rewind() functions, making this a pure Annex K checker. There is an overlapping with another recommendation (https://wiki.sei.cmu.edu/confluence/display/c/ERR07-C.+Prefer+functions+that+support+error+checking+over+equivalent+functions+that+don%27t), these functions are also listed there.

"It seems like none of these projects actually use the annex K functions, which is not really a surprise.
VLC and lighttpd seems to use it. @futogergely could you please run your check on those projects?"

"L129 and L135 are uncovered by tests. The rest of the lines are covered by tests, according to lcov."
This happens if STDC_WANT_LIB_EXT1 is defined empty (L129) or STDC_WANT_LIB_EXT1 is not literal (numeric constant, ...).

In D91000#3161296, @whisperity wrote:

Should/does this work in C++ mode for std::whatever?

x64 debian failed

ping

clang-format

formatting in instantiate-local-class.cpp