LGTM.com - false positive: size_t expression has no side effects

[andyhhp]

I'm transitioning a project from LGTM.com to Github Actions CodeQL. This particular issue shows up in both cases and is (I think) the root cause of a huge amount of collateral damage.

https://github.com/TrenchBoot/secure-kernel-loader/security/code-scanning/14 https://lgtm.com/projects/g/TrenchBoot/secure-kernel-loader/snapshot/c4099c3177cf609584076395d2679c858e6db396/files/string.c?sort=name&dir=ASC&mode=heatmap#x9221e82d90bfad26:1

This is bizarre. size_t is a type, not an expression, and the line as a whole is very much necessary here.

Trenchbook SKL is a small embedded environment, so defines its own things rather than using the system headers. In this case, size_t is just a typedef for unsigned long, and presented in the single header file included by this source.

Is the parser choking on size_t (strlen)(const char *s) by any chance? The extra brackets around the function name is an uncommon construct to find in C, but it is in fact the C spec recommended way of preventing macro expansion happening to the name strlen.

This matters for freestanding builds, where builtins aren't available by default and need manually retrofitting with something of the form

size_t strlen(const char *s);         // Real function declaration
#define strlen(s) __builtin_strlen(s) // Try optimisation all calls to strlen()
...
size_t (strlen)(const char *s)        // Prevent the #define from renaming the real function implementation
{
    ....