CLANG flagged error

[Daniel Páscoa]

Description:
SPAMR/CLANG point out to a possible deference to a null pointer. However, this issue has already been checked by the RTEMS team and flagged as false positive (see rtems-6-sparc-gr740-smp-3/doc/paf/spamr/spamr.pdf page 29).

Yet, the justification sentence ends with "Why CLANG complains about a possible null pointer at this place in code and not everywhere or nowhere remains a mystery" which sounds awkward and lead us to think that a complete analysis as not been done on the error.

Looking at it now, "_Chain_Initialize_one" is declared as static inline in a .h. That makes it public and so not all calls are controlled.
Within the function, there is already an assert operation for one of the inputs. Now, one needs to add it also to the other one. Note that this assert is only active when compiler options RTEMS_DEBUG or RTEMS_STATIC_ANALYSIS are used which shall remove the CLANG error and not influence the flight executable.

(Missions might do an early compilation with RTEMS_DEGUG to spot any problem on this).

Additional Notes:
This ticket was raised as an outcome of the Independent SW Verification and Validation (ISVV) for ESA-promoted RTEMS SMP Qualification Data Packs (​https://rtems-qual.io.esa.int). Original ISVV reference for this issue is RTEMS-SMP-CODE-VER-062.

File list:
cpukit\include\rtems\score\chainimpl.h (line 525)

[Sebastian Huber]

Functions starting with an underscore are reserved for the RTEMS implementation and not a part of the API.

Adding an _Assert(x != NULL) to pointer parameters of internal functions in general makes no sense.

I reviewed the related clang analysis. The problem is that clang doesn't know that _Scheduler_Count is greater than zero.

[Sebastian Huber <sebastian.huber@…>]

In 45393975/rtems:

score: Help static analysis in thread init

Add an assert to _Thread_Initialize_scheduler_and_wait_nodes() which may
help a static analyzer. Use a do/while loop since we have at least one
scheduler.

Update #4832.