An Attempt of Static Code Analysis of TinyVM and FreeRDP

GitHub Projects:
FreeRDP —

TinyVM —

FreeRDP Observations

The code *((trio_long_double_t *)target) = infinity; encased in the following block:

if (flags & FLAGS_LONGDOUBLE) {

*((trio_long_double_t *)target) = infinity;


returns a “Possible null pointer deference: target” cppcheck error message because of the negligence to add a block check for null before accessing the variables involved in the operation. I came to this conclusion from evaluation of the blocks surrounding line 6589 and comparing the issue to other reported cppcheck “Possible null pointer deference” errors generated from different code posted on Q&A forums such as Stack Overflow and Quora.

The second cppcheck error was “va_list ‘unused’ used before va_start() was called”, this occurs in 15 different lines because of return TrioFormat calls such as this one:

return TrioFormat(&fd, 0, TrioOutStreamFileDescriptor, format, unused, TrioArrayGetter, args);

This return call is used in different methods with the purpose of printing or scanning for example printing to the file descriptor, printing to the standard output stream, scanning characters from a string, etc.

From evaluating the code, these errors seem like false positives. The missing opens for va_list ‘unused’ aren’t actually missing opens they just mean the code opens in a different function. These are reassignment warnings that don’t take into account the use of the address of the variable so it therefore doesn’t notice the functions attached are in fact using it. So, for this error my recommendations for improvement is to dismiss the errors.

TinyVM Observations

TinyVM only returned two cppcheck issues but to address the most easily fixable error, “Common realloc mistake: ‘breakpoints’ nulled but not freed upon failure” we see the following code on line 49:

case 0x2: breakpoints = realloc(breakpoints, sizeof(struct tdb_breakpoint) * ++num_breakpoints);

These types of memory allocation issues in cppcheck when variables are declared “nulled but not freed upon failure” occur because in the event of the realloc failing then the original memory allocation exists but is leaked because it is no longer referenced by the attached variable (in this case the variable breakpoint). In short terms, they’re memory leaks stemming from reallocation. So, the solution and recommendation for improvement is to keep a handle on the original allocation until the new allocation is verified as valid. Do this with a block of if-else code that checks if new_data is NULL and if it isn’t (thus the else) it’s been verified as valid and you can set the variable equal to new_data in the else statement.


TinyVM — Static Code Analysis Output

FreeRDP — Static Code Analysis Output



Get the Medium app
