QP/C  7.3.3
Real-Time Embedded Framework
Loading...
Searching...
No Matches
Deviations

Guideline Compliance Summary (GCS)

Deviation UIDs

The deviations referenced in the compliance summary are identified using Unique Identifiers (UIDs) with the following structure:

UID for a MISRA Deviation Permits/Records:

+++------------------- 1. Work artifact class ('DVP' Deviation Permit, 'DVR' Deviation Record)
||| ++---------------- 2. Project identifier ('QP' for QP Framework, 'QS' for QP/Spy Software Tracing)
||| || +++------------ 3. Coding standard (MC3 for MISRA-C:2023)
||| || ||| +---------- 4. Directive ('D') or Rule ('R')
||| || ||| |++-++----- 5. Guideline number (e.g., R08_07 for Rule 8.7)
||| || ||| ||| ||  +-- 6. Optional variant letter ('A', 'B', 'C'...)
||| || ||| ||| ||  |
DVP-QP-MC4-Rxx-yy[-A]

Examples:

Deviation Permits

This section presents Deviation Permits for the MISRA-C:2023 deviations in the Application code, which are caused by the QP/C framework design or implementation. This section also describes workarounds to avoid some deviations.

Remarks
  • Most of the Deviation Permits in this section pertain also to the QP/C source code.
  • The Deviation Permits listed below use the section "Restrictions" instead of "Requirements" suggested in [MISRA-Comply] to avoid any confusion with the system Requirements.

DVP-QP-MC4-D04_09A

DVP-QP-MC4-D04_09A
Directive 4.9(Advisory): A function should be used in preference to a function-like macro where they are interchangeable (FALSE-POSITIVE diagnosis)
Reasons
  • No reasons are given, as it is a FALSE-POSITIVE reporting in which no violation actually occurred.
Use-Case
PCLP reports violation of this advisory MISRA directive for every function-like macro definition, but without deeper analysis whether the macro is actually interchangeable with a function. Therefore, most of the PCLP violation reports for Directive 4.9 are actually only diagnosis of a possible violation of this directive (message category 2 in Section 5.3.3 of [MISRA4]). This Deviation Record pertains to situations when a macro is NOT interchangeable with a function, so the Directive 4.9 is NOT actually violated and the PCLP report represents a FALSE-POSITIVE.

Examples
The Q_REQUIRE_ID() macro specifies precondition assertion, but it cannot be replaced with a function for the reason of maintainability. This is because in case the application developer wishes to disable assertions, a macro can be redefined to generate no code and no overhead. In contrast, a function, even if empty, could cause some additional code and overhead.

. . .
// precondition assertion
Q_REQUIRE_ID(100, e != (QEvt *)0);
. . .
Event class.
Definition qp.h:147

A state-handler function performs down-casting of the received event from the base class QEvt down to the specific subclass using the function-like macro Q_EVT_CAST(). This macro contains a parameterized type-cast and for this reason it is not interchangeable with a function.

. . .
me->x = Q_EVT_CAST(MyEvt)->x;
. . .
#define Q_EVT_CAST(class_)
Definition qp.h:523
Restrictions
  • For the QP Application code, the permit is only granted for the function-like macros explicitly listed and traced to this permit UID DVP-QP-MC4-D04_09A in the qpc.lnt PCLP configuration file.
  • For the QP/C Source Code, the permit is additionally granted for the function-like macros explicitly listed and traced to this permit UID DVP-QP-MC4-D04_09A in the options.lnt PCLP configuration file.

DVP-QP-MC4-D04_09B

DVP-QP-MC4-D04_09B
Directive 4.9(Advisory): A function should be used in preference to a function-like macro where they are interchangeable (CORRECT diagnosis)
Reasons
  • Code quality (Maintainability)
  • Code quality (Performance efficiency)
  • Adopted code integration (Generated code)
Use-Case
Deviations traced to this permit (DVP-QP-MC4-D04_09B) are CORRECT diagnoses of function-like macros that could potentially be replaced by a (inline) function. However, in a widely portable code, like the QP/C Framework, it is sometimes necessary to provide configuration options, which are not easily implemented as C functions. For example, a function to calculate an integer log-base-2 of a given bitmask can be implemented very efficiently with a built-in CLZ (count-leading-zeros) instruction, but if this instruction is not supported by a given CPU architecture, log-base-2 needs to be implemented as a regular function. In that case QP/C defines QF_LOG2() as a function-like macro, which can be redefined as needed.
Example
The QF_LOG2() function-like macro could be replaced with a function, but this is a performance-critical operation used in real-time schedulers, where the function call overhead and clobbering of additional CPU registers might be highly undesirable. Also, certain CPU architectures provide a hardware instruction (e.g., CLZ), which can be used to efficiently implement QF_LOG2(). To take advantage of such hardware accommodations, a function-like macro is preferable to a function (even if inlined).
. . .
uint8_t n = QF_LOG2(ready_set);
. . .
uint_fast8_t QF_LOG2(QPSetBits const bitmask)
Definition qf_act.c:90
Restrictions
  • This permit is only granted for the function-like macros explicitly listed and traced to this permit UID DVP-QP-MC4-D04_09B in the qpc.lnt PCLP configuration file.

DVP-QP-MC4-D04_08

DVP-QP-MC4-D04_08
Directive 4.8(Advisory): If a pointer to a structure or union is never dereferenced within a translation unit then the implementation of the object should be hidden
Reasons
  • Adopted code integration
Use-Case
In the widely portable infrastructure software, like the QP/C Framework, the provided API must be generic. Some definitions in such a generic API are not always fully de-referenced in all translation units that include the QP/C Framework header files, yet removing the definitions would break other modules that require full definitions.
Restrictions
  • This permit is only granted for the header files explicitly listed and traced to this permit UID DVP-QP-MC4-D04_08 in the qpc.lnt PCLP configuration file.

DVP-QP-MC4-R10_03

DVP-QP-MC4-R10_03
Rule 10.3(Required): The value of an expression shall not be assigned to an object with a narrower essential type or a different essential type category
Reasons
  • Code quality (Maintainability)
  • Code quality (Usability / Interoperability)
  • Adopted code integration
Use-Case
PCLP reports violation of Rule 10.3 in the application-level state machine code for the event signals in the switch statement.
Example
The following code snippet provides an example of a state-handler function:
enum {
. . .
TIMEOUT_SIG,
. . .
}
. . .
QState Philo_thinking(Philo * const me, QEvt const * const e) {
QState status_;
switch (e->sig) {
. . .
case TIMEOUT_SIG: { // <=== Rule 10.3 violation
status_ = Q_TRAN(&Philo_hungry);
break;
}
. . .
}
return status_;
}
#define Q_TRAN(target_)
Definition qp.h:499
enum QStateRet QState
Definition qp.h:223
QSignal sig
Definition qp.h:151

The Rule 10.3 violation is reported because the type of the switch discriminator e->sig is QSignal, while the type of application-level signals typically is an enumeration. Attempts to avoid deviating from this rule by defining event signals as type-cast constants as opposed to enumeration, or by type casting from enumeration to QSignal actually lower the code quality. Therefore deviation from Rule 10.3 is permitted in this particular case and context.
Restrictions
  • The deviation permit DVP-QP-MC4-R10_03 is granted only for the enumerated signals in the case statements insie the state-handler functions.

DVP-QP-MC4-R11_01

DVP-QP-MC4-R11_01
Rule 11.1(Required): Conversions shall not be performed between a pointer to a function and any other type
Reasons
  • Code quality (Maintainability / Modularity)
  • Code quality (Usability / Approprateness recognizability)
  • Adopted code integration
Use-Case
The Rule 11.1 violation occurs in the QP state machine implementation strategy, which is based on pointers to functions (state-handler functions). Notably, the first parameter in the generic state-handler signature is a pointer to the QHsm base class. However, the first parameter in the specific state-handler functions is a pointer to the subclass of QHsm. Since the QP internal implementation can only use the generic state-handlers (because specific state-handlers are defined in the QP Application), this discrepancy requires casting of the pointers to the specific state handlers on pointers to the generic state handlers, which violates Rule 11.1.
Example
The following code snippet provides an example of a state-handler function:
QState Philo_thinking(Philo * const me, QEvt const * const e) {
QState status_;
switch (e->sig) {
. . .
case TIMEOUT_SIG: {
status_ = Q_TRAN(&Philo_hungry); // <=== Rule 11.1 violation
break;
}
. . .
}
return status_;
}
. . .
// specific state-handler with "me"-pointer of type Philo rather than QHsm
QState Philo_hungry(Philo * const me, QEvt const * const e) {
. . .
}
The Rule 11.1 violation is reported because the macro Q_TRAN() has to store a pointer to the specific state-handler function &Philo_hungry in a pointer to generic state-handler function.
Restrictions
  • The deviation permit is only granted for the QP macros explicitly listed and traced to this permit UID DVP-QP-MC4-R11_01 in the qpc.lnt PCLP configuration file.

DVP-QP-MC4-R11_03A

DVP-QP-MC4-R11_03A
Rule 11.3(Required): A cast shall not be performed between a pointer to object type and a pointer to a different object type (object-oriented upcast)
Reasons
  • Code quality (Functional suitability / Functional appropriateness)
  • Adopted code integration

Use-Case
QP Framework is fundamentally object-oriented, which in the C programming language requires applying object-oriented design patterns and idioms. One of such idioms is using a pointer to a subclass in place of a pointer to the superclass. In truly object-oriented languages this is called upcasting and is performed automatically because it is safe. However, the C compimler (and the static analysis tool, like PCLP) does not "know" about the inheritance relationship between the pointers and therefore it reports violation of Rule 11.3.

Remarks
The permit DVP-QP-MC4-R11_03A is the first permit variant for Rule 11.3. See also DVP-QP-MC4-R11_03B and DVR-QP-MC4-R11_03C .
Examples
QState Calc_on(Calc * const me, QEvt const * const e) {
QState status_;
switch (e->sig) {
case C_SIG: {
. . .
status_ = QM_TRAN(&tatbl_); // <== Rule 11.3 violation
break;
}
. . .
}
return status_;
}
#define QM_TRAN(tatbl_)
Definition qp.h:570
The Rule 11.3 is violated in the macro QM_TRAN(), which needs to perform an upcast from QMsm to QHsm.
Restrictions
  • This permit is only granted for the function-like macros explicitly listed and traced to this permit UID DVP-QP-MC4-R11_03A in the qpc.lnt PCLP configuration file.

DVP-QP-MC4-R11_03B

DVP-QP-MC4-R11_03B
Rule 11.3(Required): A cast shall not be performed between a pointer to object type and a pointer to a different object type (object-oriented downcast)
Reasons
  • Code quality (Functional suitability / Functional appropriateness)
  • Adopted code integration

Use-Case
QP Framework is fundamentally object-oriented, which in the C programming language requires applying object-oriented design patterns and idioms. One of such idioms is casting a pointer to a superclass on a pointer to the subclass. In object-oriented languages this is called downcasting. Downcast is not as safe as upcast and requires some additional type information to choose the right subclass, but still the types are closely related.

Remarks
The permit DVP-QP-MC4-R11_03B is the first permit variant for Rule 11.3. See also DVP-QP-MC4-R11_03A and DVR-QP-MC4-R11_03C.
Examples
case EAT_SIG:
if (Q_EVT_CAST(TableEvt)->philoNum == PHILO_ID(me)) . . .
Restrictions
  • This permit is only granted for the QP macros explicitly listed and traced to this permit UID DVP-QP-MC4-R11_03B in the qpc.lnt PCLP configuration file.

DVP-QP-MC4-R12_03

DVP-QP-MC4-R12_03
Rule 12.3(Advisory): The comma operator should not be used
Reasons
  • Code quality (Maintainability)
  • Code quality (Usability)
  • Adopted code integration
Use-Case
QP Framework uses the comma operator in the macros for state machine implementation (Q_SUPER(), Q_TRAN(), Q_TRAN_HIST(), QM_ENTRY(), QM_EXIT(), QM_TRAN(), etc.) These macros are not replaceable by (inline) functions because of the necessary type casting, as described in DVP-QP-MC4-R11_03A and DVP-QP-MC4-R11_01.
Examples
static QState Calc_on(Calc * const me, QEvt const * const e) {
QState status_;
switch (e->sig) {
. . .
case OFF_SIG: {
status_ = Q_TRAN(&Calc_final); // <== Rule 12.3 violation
break;
}
default: {
status_ = Q_SUPER(&QHsm_top); // <== Rule 12.3 violation
break;
}
}
return status_;
}
#define Q_SUPER(super_)
Definition qp.h:509
Restrictions

DVP-QP-MC4-R13_04

DVP-QP-MC4-R13_04
Rule 13.4(Advisory): The result of an assignment operator shall not be used
Reasons
  • No reasons are given, as it is a FALSE-POSITIVE reporting in which no violation actually occurred.
Use-Case
PLCP reports violation of this advisory MISRA rule whenever assignment is used on the left-hand side of the comma operator, which is already reported in DVP-QP-MC4-R12_03. However, in all cases this happens in QP Framework code, the result of the assignment is discarded and not used.
Restrictions
  • Even though the violation of Rule 13.4 does not occur, the permit is still provided for the specific reporting of the PLCP static analysis tool. The permit applies only to the macros explicitly listed in the qpc.lnt PCLP configuration file.

DVP-QP-MC4-R19_02

DVP-QP-MC4-R19_02
Rule 19.2(Advisory): The union keyword should not be used
Reasons
  • Code quality (Performance efficiency / Resource utilization)
Use-Case
For QP Framework, deviation from this rule occurs in the data type QAsmAttr, which specifies the private state machine attribute in the QHsm base class. The use of a union in this case is strictly encapsulated inside that class code and is never accessed in the QP Application. The justifications for deviating from the Rule 19.2 are significant savings in RAM for every state machine in the system. Additionally, this deviation is strictly encapsulated inside the QP Framework (in the QHsm base class) and has no impact on QP Applications.
Restrictions
  • This permit is only granted for the QAsmAttr data type traceable to this permit UID DVP-QP-MC4-R19_02 in the qpc.lnt PCLP configuration file.

Deviation Permits for QS

This section presents Deviation Permits for the MISRA-C:2023 deviations in the Application code, which are caused by the software tracing instrumentation (QP/Spy) built into the QP Framework and available to QP Applications as well. These deviation permits are separated out because they occur only when the QP/Spy instrumentation is enabled.

Attention
In safety-related QP Application code (configured for the product release), the QS software tracing shall be inactive (the macro Q_SPY shall NOT be defined). In that case, the deviations included in this section are simply NOT present.

DVP-QS-MC4-D04_09A

DVP-QS-MC4-D04_09A
Directive 4.9(Advisory): A function should be used in preference to a function-like macro where they are interchangeable (FALSE-POSITIVE diagnosis)
Reasons
  • No reasons are given, as it is a FALSE-POSITIVE reporting in which no violation actually occurred.
Use-Case
See background of deviation permit DVP-QP-MC4-D04_09A.
Restrictions
  1. For the QP Application code, the permit is only granted for the function-like macros explicitly listed and traced to this permit UID DVP-QS-MC4-D04_09A in the qpc.lnt PCLP configuration file.
  2. For the QP/C Source Code, the permit is additionally granted for the function-like macros explicitly listed and traced to this permit UID DVP-QS-MC4-D04_09A in the options.lnt PCLP configuration file.
Examples
The QS_...() macros cannot be replaced with a function for the reason of maintainability. This is because in case the application developer wishes to disable QS software tracing, the macros can be redefined to generate no code and no overhead. In contrast, functions, even if empty, could cause some additional code and overhead.
. . .
QS_BEGIN_ID(COMMAND_STAT, 0U) // app-specific record
QS_U8(2, cmdId);
QS_U32(8, param1);
QS_U32(8, param2);
QS_U32(8, param3);
. . .
#define QS_U8(width_, data_)
Definition qs.h:397
#define QS_U32(width_, data_)
Definition qs.h:413
#define QS_END()
Definition qs.h:356
Restrictions
  • The deviation permit is only granted for the QS macros explicitly listed and traced to this permit UID DVP-QS-MC4-D04_09A in the qpc.lnt PCLP configuration file.

DVP-QS-MC4-R11_01

DVP-QS-MC4-R11_01
Rule 11.1(Required): Conversions shall not be performed between a pointer to a function and any other type
Reasons
  • Code quality (Usability)
  • Adopted code integration
Use-Case
The QS software tracing instrumentation deviates from Rule 11.1 in the macros QS_FUN_DICTIONARY() and QS_TEST_PROBE_DEF(), where the conversion of pointers to function conversion needs to be performed. In case of the QS_FUN_DICTIONARY() macro, the pointer needs to be serialized. In case of the QS_TEST_PROBE_DEF() macro the pointer needs to be stored in a generic array of pointers to function. The most important consideration is that in both cases the pointer to function (after casting) is never dereferenced.

Examples
The following state-handler for a top-most initial transition in a state machine produces "QS Function Dictionaries" with the macro QS_FUN_DICTIONARY():

QState Calc_initial(Calc * const me, void const * const par) {
. . .
QS_FUN_DICTIONARY(&Calc_on); // <== Rule 11.1 violation
QS_FUN_DICTIONARY(&Calc_error); // <== Rule 11.1 violation
. . .
#define QS_FUN_DICTIONARY(fun_)
Definition qs.h:517

The following implementation of the QActive_post_() function defines the "QS Test Probe" with the macro QS_TEST_PROBE_DEF(). This "QS test probe" is subsequently used for fault injection during testing.

bool QActive_post_(QActive * const me, ...) {
. . .
// test-probe#1 for faking queue overflow
QS_TEST_PROBE_DEF(&QActive_post_) // <== Rule 11.1 violation
nFree = 0U;
)
. . .
}
#define QS_TEST_PROBE_DEF(fun_)
Definition qs.h:846
#define QS_TEST_PROBE_ID(id_, code_)
Definition qs.h:852
Active object class (based on the QHsm implementation strategy)
Definition qp.h:800
Restrictions
  • The deviation permit is only granted for the QS macros explicitly listed and traced to this permit UID DVP-QS-MC4-R11_01 in the qpc.lnt PCLP configuration file.

DVP-QS-MC4-R20_10

DVP-QS-MC4-R20_10
Rule 20.10(Advisory): The # and ## preprocessor operators should not be used
Reasons
  • Code quality (Maintanability / Testability)
  • Adopted code integration
Use-Case
Deviation from this rule occurs in the QS software tracing instrumentation in the macros producing "dictionary entries". Those "dictionaries" provide the symbolic information to the software tracing system, so that the binary addresses of various objects and functions can be displayed using symbolic names from the program. The stringize and concatenation preprocessor operators are necessary in this case to convent the symbolic names in the program into ASCII strings that can be sent to the host.
Examples
The following state-handler for a top-most initial transition in a state machine produces "QS Function Dictionaries" as well as "QS Object Dictionary":
QState Calc_initial(Calc * const me, void const * const par) {
. . .
QS_FUN_DICTIONARY(&Calc_on); // <== Rule 20.10 violation
QS_OBJ_DICTIONARY(&Calc_inst); // <== Rule 20.10 violation
. . .
#define QS_OBJ_DICTIONARY(obj_)
Definition qs.h:509
Restrictions
  • The deviation permit is only granted for the QS macros explicitly listed and traced to this permit UID DVP-QS-MC4-R20_10 in the qpc.lnt PCLP configuration file.

Deviation Records

Deviation Records in this section document MISRA-C:2023 deviations in the QP/C source code. These deviations are contained in the QP/C code and don't cause deviations in the QP Applications.

DVR-QP-MC4-R08_13

DVR-QP-MC4-R08_13
Rule 8.13(Advisory): A pointer should point to a const-qualified type whenever possible
Reasons
  • Code quality (Portability / Adaptability)
Background
The QP Framework adheres to the Rule 8.13 quite strictly, with just a few exceptions for portability. Specifically the QP base class QActive defines generic operations (e.g., start()), which need to be implemented in various QP adaptations. Some of these implementations (e.g., in the QV, QK, and QXK kernels) might use the pointer parameters such that the const qualification would be possible. However, the const qualification would not be applicable for all other QP ports. Therefore, under the restriction of providing one, common API, Rule 8.13 is not followed in the few exceptional cases for reasons of portability and adaptability.
Examples
The following code fragment shows the QActive_start_() implementation for the QV kernel. The function does not use the stack parameters, which in this particular case could be defined const:
void QActive_start_(QActive * const me,
QPrioSpec const prioSpec,
QEvt const * * const qSto,
uint_fast16_t const qLen,
void * const stkSto, // <== could be void const * const stkSto
uint_fast16_t const stkSize,
void const * const par)
{
Q_UNUSED_PAR(stkSto); // not needed in QV
. . .
}
#define Q_UNUSED_PAR(par_)
Definition qp.h:532
uint16_t QPrioSpec
Definition qp.h:619
Restrictions
  • The deviation is only permitted in the QP functions explicitly listed and traced to this record UID DVR-QP-MC4-R08_13 in the options.lnt PCLP configuration file.

DVR-QP-MC4-R11_03C

DVR-QP-MC4-R11_03C
Rule 11.3(Required): A cast shall not be performed between a pointer to object type and a pointer to a different object type (unrelated types)
Reasons
  • Code quality (Reliability)
Background
QP Framework performs casts between unrelated pointer types in the blocking QXK kernel to store the blocking object pointers in the exterded thread (QXThread class) for subsequent integrity checks. These checks are part of the QP Software Self-Monitoring (SSM) and are added for improved reliability.
Examples
The following code fragment shows the QActive_start_() implementation for the QV kernel. The function does not use the stack parameters, which in this particular case could be defined const:
bool QXThread_delay(uint_fast16_t const nTicks) {
. . .
// the blocking object must be the time event, part of SIS
Q_ENSURE_ID(890, thr->super.super.temp.obj
== QXK_PTR_CAST_(QMState const*, &thr->timeEvt));
thr->super.super.temp.obj = (QMState *)0; // clear
. . .
}
#define Q_ENSURE_ID(id_, expr_)
Definition qsafe.h:139
#define QXK_PTR_CAST_(type_, ptr_)
Definition qxk.h:363
State object for the QMsm class (QM State Machine).
Definition qp.h:239
Restrictions
  • The deviation is only permitted in the internal QP macro QXK_PTR_CAST_() explicitly listed and traced to this record UID DVR-QP-MC4-R11_03C in the options.lnt PCLP configuration file.

DVR-QP-MC4-R11_04

DVR-QP-MC4-R11_04
Rule 11.4(Advisory): A conversion should not be performed between a pointer to object and an integer type
Reasons
  • Code quality (Reliability)
Background
The QP Framework code deviates from this advisory rule only to implement Duplicate Inverse Storage (DIS) for critical pointer variables (part of the QP Functional Safety System). The deviation from this rule is encapsulated in the internal macro Q_UINTPTR_CAST_(). Specifically, the DIS technique is based on making a duplicate inverted copy of a pointer variable, which requires converting a pointer to integer.
Examples
The following example shows how a DIS is calculated and stored, and later how it is used in an assertion to verify the pointer integrity.
#ifndef Q_UNSAFE
fb->next_dis = (uintptr_t)(~Q_UINTPTR_CAST_(fb->next));
#endif
. . .
// the free block must have integrity (duplicate inverse storage)
Q_ASSERT_NOCRIT_(302, Q_UINTPTR_CAST_(fb_next)
== (uintptr_t)~fb->next_dis);
#define Q_UINTPTR_CAST_(ptr_)
Definition qp_pkg.h:97
Restrictions
  • The deviation is only permitted in the internal QP macro Q_UINTPTR_CAST_() explicitly listed and traced to this record UID DVR-QP-MC4-R11_04 in the options.lnt PCLP configuration file.
  • The result of the pointer-to-integer conversion should never be converted back to a pointer and thus never dereferenced.

DVR-QP-MC4-R11_05

DVR-QP-MC4-R11_05
Rule 11.5(Advisory): A conversion should not be performed from pointer to void into pointer to object
Reasons
  • Code quality (Functional suitability)
  • Code quality (Compatibility)
  • Code quality (Maintainability)
Background
The QP Framework code deviates from this advisory rule in a few instances, where a more general mechanism is specialized. For example, QP Framework provides deterministic memory pool (QMPool), which can be used for allocation of any type of objects. The most natural API for such generic pools is based on void* pointers. At the same time, the generic memory pools are specialized as event pools for allocating mutable events. In that case, the void* pointers must be cast to QEvt* pointers, which violates Rule 11.5.
Examples
// cast void* on QEvt*, violates Rule 11.5(A)
#define QF_EPOOL_GET_(p_, e_, m_, qsId_) \
((e_) = (QEvt *)QMPool_get(&(p_), (m_), (qsId_)))
. . .
QEvt * QF_newX_(
. . .
QF_EPOOL_GET_(QF_ePool_[idx], e,
((margin != QF_NO_MARGIN) ? margin : 0U), 0U);
. . .
return e;
}
#define QF_EPOOL_GET_(p_, e_, m_, qsId_)
Definition qk.h:207
#define QF_NO_MARGIN
Definition qp.h:1154
Restrictions
  • The deviation is only permitted in the instances explicitly listed and traced to this record UID DVR-QP-MC4-R11_05 in the options.lnt PCLP configuration file.

DVR-QP-MC4-R11_08

DVR-QP-MC4-R11_08
Rule 11.8(Required): A cast shall not remove any 'const' or 'volatile' qualification from the type pointer to by a pointer
Reasons
  • Code quality (Reliability)
  • Code quality (Functional suitability)
Background
QP Framework code deviates from this rule only in the internal (inline) functions QEvt_refCtr_inc_(), QEvt_refCtr_dec_(), and the public function QF_gc(), where the const qualification of pointers to QEvt needs to be occasionally discarded. The discarding of const is always preceded by ensuring that a given event is indeed mutable (by testing the QEvt.evtTag_ member). Deviation from this rule is considered a better tradeoff for safety and design correctness than not using the const qualification for event pointers at all.
Examples
void QF_gc(QEvt const * const e) {
. . .
// cast 'const' away, which is OK, because it's a pool event
QF_EPOOL_PUT_(QF_ePool_[poolNum - 1U], (QEvt *)e, 0U);
. . .
}
#define QF_EPOOL_PUT_(p_, e_, qsId_)
Definition qk.h:211
Restrictions
  • The deviation is only permitted in the instances explicitly listed and traced to this record UID DVR-QP-MC4-R11_08 in the options.lnt PCLP configuration file.

DVR-QS-MC4-R14_03

DVR-QS-MC4-R14_03
Rule 14.3(Required): Controlling expressions shall not be invariant
Reasons
  • Code quality (Maintainability, Testability)
Background
The QS instrumentation deviates from this rule in the macros QS_BEGIN_PRE_() and QS_BEGIN_NOCRIT_PRE_() in the inactive versions of these macros (when QS instrumentation is disabled).
Examples
The following example shows the inactive definitions of the macros QS_BEGIN_PRE_(), and QS_BEGIN_NOCRIT_PRE_().
// file qs_dummy.h
. . .
#define QS_BEGIN_PRE_(rec_, qsId_) if (false) {
#define QS_BEGIN_NOCRIT_PRE_(rec_, qsId_) if (false) {
. . .
Restrictions
  • The deviation permit is only granted for the QS macros QS_BEGIN_PRE_() and QS_BEGIN_NOCRIT_PRE_() explicitly listed and traced to this permit UID DVR-QS-MC4-R14_03 in the qpc.lnt PCLP configuration file.

DVP-QS-MC4-R15_05

DVP-QS-MC4-R15_05
Rule 15.5(Advisory): A function should have a single point of exit at the end
Reasons
  • Code quality (Maintanability / Testability)
  • Adopted code integration
Background
Deviation from this rule occurs only in the QS/QUTest software tracing and testing instrumentation. Specifically, an additional return occurs when events are posted to the QActiveDummy test-double or the QS_TEST_PROBE() macro used. The justification is that such additional return point is used only for temporarily altering the CUT (Code Under Test) when a test-double it used or for error injection (e.g., to return a specific error to the caller.)
Restrictions
  • The deviation is only permitted in the QS/QUTest software tracing functions and macros explicitly listed and traced to this permit UID DVP-QS-MC4-R15_05 in the qpc.lnt PCLP configuration file.

DVR-QP-MC4-R18_03

DVR-QP-MC4-R18_03
Rule 18.3(Required): The relation operators shall not be applied to objects of pointer type except where they point into the same array
Reasons
  • Code quality (Reliability)
Background
Deviation from this rule occurs in the assertions in the QMPool_get() and QMPool_put() operations. The assertions check that the pointer to a memory block indeed comes from the memory pool by range-checking the pointer. If the block belongs to the pool, the pointer comparison is made within the same array, so the rule is actually not violated. The transgression occurs only if the block pointer is not in range. The assertions of pointer range proved to be very valuable in ensuring the system integrity and in this particular context the benefits outweigh the risk of deviating from the MISRA rule.
Examples
// NOTE: The next free block pointer can fall out of range
// when the client code writes past the memory block, thus
// corrupting the next block.
Q_ASSERT_NOCRIT_(330,
(me->start <= fb_next) && (fb_next <= me->end));
. . .
Restrictions
  • The deviation is only permitted in the the QMPool_get() and QMPool_put() operations explicitly listed and traced to this record UID DVR-QP-MC4-R18_03 in the options.lnt PCLP configuration file.

Deviation Records for QS

This section presents Deviation Records for QS software tracing and testing (QP/Spy and QUTest) and instrumentation built into the QP Framework.

Attention
In safety-related QP Application code as configured for the product release, the QS software tracing shall be inactive (the macro Q_SPY shall NOT be defined). In that case, the deviations cased by the QS tracing instrumentation are NOT present.

DVR-QS-MC4-R08_13

DVR-QS-MC4-R08_13
Rule 8.13(Advisory): A pointer should point to a const-qualified type whenever possible
Reasons
  • Code quality (Maintainability, Testability)
Background
The deviations from this advisory rule occur only in the QUTest instrumentation, in the "dummy" test-doubles, sucha as: QHsmDummy and QActiveDummy. The reasons are similar as in DVR-QP-MC4-R08_13. Specifically the "dummy" test doubles implement the generic QF API such that the const qualification would be possible. However, the const qualification would not be applicable for all other QP ports. Therefore, under the restriction of providing one, common API, Rule 8.13 cannot be followed for the "dummy" test doubles.
Examples
void QHsmDummy_dispatch_(
QHsm * const me,
QEvt const * const e,
uint_fast8_t const qsId)
{
// NOTE: all parameters could be 'const' in this "dummy" implementation
. . .
}
Hierarchical State Machine class (QHsm-style state machine implementation strategy)
Definition qp.h:313
Restrictions

DVR-QS-MC4-R11_03C

DVR-QS-MC4-R11_03C
Rule 11.3(Required): A cast shall not be performed between a pointer to object type and a pointer to a different object type (unrelated objects)
Reasons
  • Code quality (Maintainability, Testability)
Background
The QS instrumentation deviates from this rule in the files qs_rx.c and qutest.c, where a generic array of void* pointers to "current objects" is cast to specific objects to execute the external commands (see also DVR-QS-MC4-R11_05).
Examples
The following code fragment shows the QActiveDummy_init_() implementation performs a downcast from the QHsm* base class to the QActive* subclass:
void QActiveDummy_init_(
QHsm * const me,
void const * const par,
uint_fast8_t const qsId)
{
. . .
QHsmDummy_init_(me, par, ((QActive const *)me)->prio); // <==
}
Restrictions
  • The deviation is only permitted in the internal QP macro QXK_PTR_CAST_() explicitly listed and traced to this record UID DVR-QP-MC4-R11_03C in the options.lnt PCLP configuration file.

DVR-QS-MC4-R11_04

DVR-QS-MC4-R11_04
Rule 11.4(Advisory): A conversion should not be performed between a pointer to object and an integer type
Reasons
  • Code quality (Maintainability, Testability)
Background
The QS instrumentation deviates from this rule in the code that serializes pointers. In all such type of code, the binary addresses are sent as integeres and casting from integers to pointers is unavoidable.
Examples
The following example shows internal function to serialize object pointers.
// file qs.c
void QS_obj_raw_(void const * const obj) {
#if (QS_OBJ_PTR_SIZE == 1U)
QS_u8_raw_((uint8_t)obj); // <===
#elif (QS_OBJ_PTR_SIZE == 2U)
QS_u16_raw_((uint16_t)obj); // <===
#elif (QS_OBJ_PTR_SIZE == 4U)
QS_u32_raw_((uint32_t)obj); // <===
#elif (QS_OBJ_PTR_SIZE == 8U)
QS_u64_raw_((uint64_t)obj); // <===
#else
QS_u32_raw_((uint32_t)obj); // <===
#endif
}
Restrictions
  • The deviation is only permitted in the QS macros and functions explicitly listed and traced to this record UID DVR-QS-MC4-R11_06 in the options.lnt PCLP configuration file.

DVR-QS-MC4-R11_05

DVR-QS-MC4-R11_05
Rule 11.5(Advisory): A conversion should not be performed from pointer to void into pointer to object
Reasons
  • Code quality (Maintainability, Testability)
Background
The QS instrumentation deviates from this advisory rule in the files qs_rx.c and qutest.c, where a generic array of void* pointers "current objects" is cast to specific objects to execute the external commands.
Examples
// file qutest.c
void QS_rxHandleGoodFrame_(uint8_t const state) {
. . .
QHsm * const hsm = (QHsm *)QS_rxPriv_.currObj[SM_OBJ]; // <===
. . .
}
@ SM_OBJ
state machine object
Definition qs.h:960
Restrictions
  • The deviation is only permitted in the files qs_rx.c and qutest.c explicitly listed and traced to this record UID DVR-QS-MC4-R11_05 in the options.lnt PCLP configuration file.

DVR-QS-MC4-R11_06

DVR-QS-MC4-R11_06
Rule 11.6(Required): A cast shall not be performed between pointer to void and an arithmetic type
Reasons
  • Code quality (Maintainability, Testability)
Background
The QS instrumentation deviates from this rule in the code that serializes. In all such type of code, the binary addresses are sent as integeres and casting from pointers to integers is unavoidable (see also DVR-QS-MC4-R11_04).
Examples
The following example shows internal function to serialize object pointers.
// file qutest.c
uint32_t QS_getTestProbe_(QSpyFunPtr const api) {
. . .
for (i = 0U; i < QS_testData.tpNum; ++i) {
. . .
if (QS_testData.tpBuf[i].addr == (QSFun)api) { // <===
. . .
}
}
. . .
}
Restrictions
  • The deviation is only permitted in the QS macros and functions explicitly listed and traced to this record UID DVR-QS-MC4-R11_06 in the options.lnt PCLP configuration file.

DVR-QS-MC4-R19_02

DVR-QS-MC4-R19_02
Rule 19.2(Advisory): The union keyword should not be used
  • Code quality (Maintainability, Testability)
Background
The QS instrumentation deviates from this rule in the internal functions QS_f32_fmt_() and QS_f64_fmt_() for serialization of floating point numbers. Specifically, the unions are used to obtain the binary representation of floating point numbers, which then can be serialized as a sequence of bytes.
Examples
The following example shows a union that holds a 32-bit float and 32-bit integer for obtaining the binary representation of the float.
// file qs_fp.c
void QS_f32_fmt_(
uint8_t const format,
float32_t const d)
{
union F32Rep {
uint32_t u;
} fu32; // the internal binary representation
. . .
}
float float32_t
Definition qp.h:112
Restrictions
  • The deviation is only permitted in the QS the internal functions QS_f32_fmt_() and QS_f64_fmt_() explicitly listed and traced to this record UID DVR-QS-MC4-R19_02 in the options.lnt PCLP configuration file.

Deviation Permits for PCLP

The deviation permits in this section are for additional diagnostics generated by the PCLP static analysis tool that go beyond MISRA-C:2023. The purpose of these permits is to allow suppressing these diagnostics in the QP Application code, so that the application code passes cleanly analysis with PCLP. Of course, the diagnostic suppression is only contextual, and the PCLP diagnostics is in force for all other contexts.

DVP-QS-PCLP-641

DVP-QS-PCLP-641
Implicit conversion of enum to integral type int
Reasons
  • Code quality (Maintainability, Testability)
Use-Case
PCLP generates this diagnostics in the QS tracing instrumentation, in the macro QS_SIG_DICTIONARY(). This macro generates the symbolic information (so called "dictionary") for the provided event signal. For the ease of maintenance, signals are generally specified as enumerations, so the QS_SIG_DICTIONARY() macro must perform casting from enum to integral type.
Examples
QState MyAO_initial(Table * const me, QEvt const *) {
. . .
// signals for the state machine "me"...
QS_SIG_DICTIONARY(DONE_SIG, me); // <==
. . .
}
#define QS_SIG_DICTIONARY(sig_, obj_)
Definition qs.h:505
Restrictions
  • The deviation is only permitted in the QS the QS_SIG_DICTIONARY() macro explicitly listed and traced to this record UID DVP-QS-PCLP-641 in the qpc.lnt PCLP configuration file.

DVP-QP-PCLP-823

DVP-QP-PCLP-823
Definition of macro ends in semicolon
Reasons
  • Code quality (Reliability)
Use-Case
PCLP generates this diagnostics in the macros Q_DEFINE_THIS_MODULE() and Q_DEFINE_THIS_FILE() used in QP assertions. These macros define a single copy of a module name string (at the file scope). If these macros would not end in semicolon, the semicolon would have to be provided externally. However, this wouild be a problem in case assertions are disabled because then a single semicolon would be syntactically incorrect at the top of a C source file.
Examples
// file main.c
#include "qpc.h"
. . .
Q_DEFINE_THIS_MODULE("main")
. . .
QP/C interface including the backwards-compatibility layer.
Restrictions
  • The deviation is only permitted in the macros Q_DEFINE_THIS_MODULE() and Q_DEFINE_THIS_FILE() explicitly listed and traced to this record UID DVP-QP-PCLP-823 in the qpc.lnt PCLP configuration file.

DVP-QS-PCLP-823

DVP-QS-PCLP-823
Definition of macro ends in semicolon
Reasons
  • Code quality (Maintainability, Testability)
Use-Case
PCLP generates this diagnostics in the macro QS_TEST_PROBE_DEF() used in QUTest testing harness. This macro defines a generic "test probe" and if it would not end in semicolon, the semicolon would have to be provided externally. However, this wouild be a problem in case testing is disabled because then a single semicolon would be syntactically incorrect at the top of a C source file.
Examples
static uint32_t myFun(void) {
QS_TEST_PROBE_DEF(&myFun) // <==
return qs_tp_;
)
return 0;
}
#define QS_TEST_PROBE(code_)
Definition qs.h:849
Restrictions
  • The deviation is only permitted in the macro QS_TEST_PROBE_DEF() explicitly listed and traced to this record UID DVP-QS-PCLP-823 in the qpc.lnt PCLP configuration file.

DVP-QP-PCLP-826

DVP-QP-PCLP-826
Suspicious pointer-to-pointer conversion (area too small)
Reasons
  • Code quality (Maintainablity)
Use-Case
PCLP generates this diagnostics in the macros Q_EVT_CAST(), QACTIVE_POST(), QACTIVE_POST_X(), QACTIVE_POST_LIFO(), Q_NEW(), and Q_NEW_X(). The reason seems to be the downcast of the superclass pointers (e.g., QEvt*) to specific subclasses (e.g., ReminderEvt*).
Examples
// state-handler function
QState MyActive_active(MyActive * const me, QEvt const * const e) {
QState status_;
switch (e->sig) {
case Q_ENTRY_SIG: {
ReminderEvt *reminder = Q_NEW(ReminderEvt, CRUNCH_SIG); // <==
. . .
status_ = Q_HANDLED();
break;
}
//${Components::Cruncher::SM::processing::CRUNCH}
case CRUNCH_SIG: {
uint32_t i = Q_EVT_CAST(ReminderEvt)->iter; // <==
. . .
status_ = Q_HANDLED();
break;
}
}
}
#define Q_HANDLED()
Definition qp.h:514
#define Q_NEW(evtT_, sig_,...)
Definition qp.h:1167
@ Q_ENTRY_SIG
signal for coding entry actions
Definition qp.h:257
Restrictions
  • The deviation is only permitted in the macros explicitly listed and traced to this record UID DVP-QS-PCLP-823 in the qpc.lnt PCLP configuration file.

Deviation Records for PCLP

The deviation records in this section are for additional diagnostics generated by the PCLP static analysis tool that go beyond MISRA-C:2023.

DVR-QS-PCLP-506

DVR-QS-PCLP-506
Constant value used in Boolean context (left operand to || operator)
Reasons
  • Code quality (Maintainability, Testability)
Background
PCLP generates this diagnostics for the QS software tracing macros QS_BEGIN_PRE_() and QS_BEGIN_NOCRIT_PRE_() for certain constant settings of the "global" and "local" QS filters, which can happen in the QP application code.
Restrictions
  • The deviation is only permitted for the QS macros QS_BEGIN_PRE_() and QS_BEGIN_NOCRIT_PRE_() explicitly listed and traced to this permit UID DVR-QS-PCLP-506 in the options.lnt PCLP configuration file.

DVR-QS-PCLP-572

DVR-QS-PCLP-572
Excessive shift value (precision 0 shifted right by ...)
Reasons
  • Code quality (Maintainability)
Background
PCLP generates this diagnostics for the QS software tracing macros QS_BEGIN_PRE_() and QS_BEGIN_NOCRIT_PRE_() for certain constant settings of the "global" and "local" QS filters, which can happen in the QP application code.
Restrictions
  • The deviation is only permitted for the QS macros QS_BEGIN_PRE_() and QS_BEGIN_NOCRIT_PRE_() explicitly listed and traced to this permit UID DVR-QS-PCLP-572 in the options.lnt PCLP configuration file.

DVR-QS-PCLP-708

DVR-QS-PCLP-708
Union initialization
Reasons
  • Code quality (Maintainability )
Background
PCLP generates this diagnostics for the QS software tracing function QS_f64_fmt_().
Restrictions
  • The deviation permit is only granted for the QS function QS_f64_fmt_() explicitly listed and traced to this permit UID DVR-QS-PCLP-708 in the options.lnt PCLP configuration file.

DVR-QS-PCLP-778

DVR-QS-PCLP-778
Constant expression evaluates to 0 in binary operation >>
Reasons
  • Code quality (Maintainability)
Background
PCLP generates this diagnostics for the macros QS_BEGIN_PRE_() and QS_BEGIN_NOCRIT_PRE_() for certain constant settings of the "global" and "local" QS filters, which can happen in the QP application code.
Restrictions
  • The deviation is only permitted for the QS macros QS_BEGIN_PRE_() and QS_BEGIN_NOCRIT_PRE_() explicitly listed and traced to this permit UID DVR-QS-PCLP-778 in the options.lnt PCLP configuration file.

DVR-QS-PCLP-845

DVR-QS-PCLP-845
The right operand to << always evaluates to 0
Reasons
  • Code quality (Maintainability) PCLP generates this diagnostics for the QS software tracing macros QS_BEGIN_PRE_() and QS_BEGIN_NOCRIT_PRE_() for certain constant settings of the "global" and "local" QS filters, which can happen in the QP application code.
Restrictions
  • The deviation is only permitted for the QS macros QS_BEGIN_PRE_() and QS_BEGIN_NOCRIT_PRE_() explicitly listed and traced to this permit UID DVR-QS-PCLP-845 in the options.lnt PCLP configuration file.

DVR-QP-PCLP-2445

DVR-QP-PCLP-2445
Cast increases required alignment from 2 to 4
Reasons
  • Code quality (Maintainability) PCLP generates this diagnostics for the internal QXK macro QXK_PTR_CAST_(). That macro is used to cast a pointer to a blocking object to store it in the exterded thread (QXThread class) for subsequent integrity checks. These checks are part of the QP Software Self-Monitoring (SSM) and are added for improved reliability.
Restrictions
  • The deviation is only permitted for the macro QXK_PTR_CAST_() explicitly listed and traced to this permit UID DVR-QS-PCLP-845 in the options.lnt PCLP configuration file.

Guideline Compliance Summary (GCS)