We are using Klocwork to perform a static code analysis, an it has found the following critical defect “Constant NULL may be dereferenced by passing argument 2 to function ‘xQueueGenericSend’” on 3 functions: vSemaphoreCreateBinary, xSemaphoreGive and prvInitialiseMutex
we are using FreeRTOS version 10.2.1
Has anyone find any issues on memory corruption because of these functions, I’m worry because we implement configASSERT only for debug compilation mode, but it goes to no code for release
The Static Analyzer just isn’t being smart enough. (Going from memory of the code) In all those cases while a NULL buffer pointer is passed, if the functions have been used right, the item size has also been set to zero, so the function won’t use the NULL data pointer. The Static Analyzer doesn’t see this correlation (and in fact you could get that error if you did something like call xSemaphoreGive on a normal Queue, but that is an error of the caller, which at least in most cases will be detected with an assert, so will be caught during debug, assuming you fully test your code in debug mode.
If you run/test your code with configASSERT() defined, and do with good coverage, then this line will catch a misuse of the second parameter. Assuming your code is a single statically linked executable, so what you run with configASSERT() defined is the same as you run when it is not defined, then the code is safe. Passing NULL in as the second parameter is valid as that is what semaphores do, so if you create semaphores and use the semaphore API on those semaphores then the code is good. If you were to create a semaphore and then use that semaphore with a queue function you would first get compiler warnings about type mismatches, and then the assert() would trigger.