Main Content

Invalid result of AUTOSAR runnable implementation

Return value or output arguments violate AUTOSAR specifications

Description

This check evaluates functions implementing AUTOSAR runnables. The check determines if the output arguments and return value from the runnable can violate AUTOSAR specifications at run-time.

This check is enabled only if you run a Code Prover analysis based on AUTOSAR ARXML specifications, either in the Polyspace® user interface or using the polyspace-autosar command. For more information, see Run Polyspace on AUTOSAR Code.

Diagnosing This Check

Using the information on the Result Details pane, determine whether the return value or an argument violates data constraints in the AUTOSAR XML specifications or can be NULL-valued. Look for the ! icon that indicates a definite error or the ? icon that indicates a possible error.

For each output argument and the return value, the check looks for these violations:

  • Data constraint violations:

    Suppose, in this implementation of the runnable foo, the return value, which represents an application error, has an enumeration data type with a finite set of values. The analysis checks if the return value can acquire a value outside that set at run time.

    iOperations_ApplicationError foo(
    Rte_Instance const self,
    app_Array_2_n320to320ConstRef aInput,
    app_Array_2_n320to320Ref aOutput,
    app_Enum001Ref aOut2) {
...
}
    The check can result in a message such as this. The message indicates that the argument has a value that falls outside the constrained range (in this case, the value 43).

    In general, the analysis verifies if each output argument of the runnable and the return value stays within the constrained range allowed by their AUTOSAR data types. You limit values of AUTOSAR data types by referring to data constraints in your ARXML files.

  • NULL or unallocated pointers:

    Suppose, in this implementation of the runnable foo, the first output argument aOutput is a pointer. The analysis checks if the pointer is non-NULL and allocated for all possible execution paths upon return from the runnable.

    iOperations_ApplicationError foo(
    Rte_Instance const self,
    app_Array_2_n320to320ConstRef aInput,
    app_Array_2_n320to320Ref aOutput,
    app_Enum001Ref aOut2) {
...
}
    The check can result in a message such as this.

    In general, the analysis verifies if a pointer output arguments from the runnable are non-NULL and allocated upon return from the runnable.

    By default, the analysis assumes that pointer arguments to runnables and pointers returned from Rte_ functions are not NULL. To change this assumption, undefine the macro RTE_PTR2USERCODE_SAFE using the option -U of the polyspace-autosar command.

    See Run Polyspace on AUTOSAR Code with Conservative Assumptions.

The check first considers the return from the runnable and then the output arguments. If the return from the runnable indicates an error, the check does not look at output arguments on execution paths with the error.

For instance, in this example, the return value is RTE_E_OK only if the output argument aOut2 is not NULL. The check does not consider other execution paths (where the return value is not RTE_E_OK). Therefore, it determines that aOut2 cannot be NULL.

// Runnable implementation
iOperations_ApplicationError foo(
    Rte_Instance const self,
    app_Array_2_n320to320ConstRef aInput,
    app_Array_2_n320to320Ref aOutput,
        app_Enum001Ref aOut2)
{
    iOperations_ApplicationError rc = E_NOT_OK;


    if (aOut2!=NULL_PTR)
    {
        // set invalid value will trigger STD_LIB RED in prove-runnable wrapper
        *aOut2 = 4;
        rc = RTE_E_OK;
    }
    return rc;
}

The reason for this behavior is the following: If the return from the runnable indicates an error status on a certain execution path, you can evaluate the error status and take corrective action. Run-time checks are not required for those paths. In certain situations, you might be using one or more output arguments to provide further information on an error status. You might want to check if those output argument can be NULL when the runnable completes execution. If you have this requirement, contact Technical Support.

The check does not flag these situations:

  • Output arguments are not written at all within the body of the runnable (or not written along certain execution paths).

  • The return value is not initialized within the body of the runnable (or not initialized along certain execution paths).

The analysis checks for conformance with data constraints only when the return value is initialized or output arguments written.

Result Information

Group: Other
Language: C
Acronym: AUTOSAR_IMPL

Version History

Introduced in R2018a

See Also

Topics