A20-8-2 / A20-8-3 - Is returning a non-owning pointer always a violation?

[vanhuynh]

Hello,

Our team uses a static analysis tool for ASIL-B compliance. The tool warns about violation of rule A20-8-2/A20-8-3 when a non-owning pointer is returned from a function:

Code:

  template <uint64_t CAPACITY>
  class FixedCapacityBuffer {
      std::array<uint8_t, CAPACITY> buffer;
      uint64_t length;

  public:
      uint8_t* Data() const noexcept { return buffer.data(); } //////////////< Violation of rule A20-8-2/A20-8-3?

      // ...
  };

Code:

 
Rule A20-8-3: "A unique_ptr shall be used to represent exclusive ownership."
Rule A20-8-3: "A std::shared_ptr shall be used to represent shared ownership."

However, I do not want to express exclusive or shared ownership. Is the warning correct or a false-positive?

[kent.dorfman766]

Hello,

Our team uses a static analysis tool for ASIL-B compliance. The tool warns about violation of rule A20-8-2/A20-8-3 when a non-owning pointer is returned from a function:

Code:

  template <uint64_t CAPACITY>
  class FixedCapacityBuffer {
      std::array<uint8_t, CAPACITY> buffer;
      uint64_t length;

  public:
      uint8_t* Data() const noexcept { return buffer.data(); } //////////////< Violation of rule A20-8-2/A20-8-3?

      // ...
  };

Code:

 
Rule A20-8-3: "A unique_ptr shall be used to represent exclusive ownership."
Rule A20-8-3: "A std::shared_ptr shall be used to represent shared ownership."

However, I do not want to express exclusive or shared ownership. Is the warning correct or a false-positive?

Do you intend to be able to modify either the pointer value returned, or the data it references? 
If you intend to be able to modify the objects internal buffer via the returned pointer then that is bad ju-ju.  If you are returning a convenience pointer to const data itself then you need to declare as

Code:

const uint8_t* fn() const;

But in some circles both would be considered "bad" since no guarantee that the pointer isn't referenced after the object itself is destroyed, thus the reason for the unique_ptr rule.

If you just want to reference read-only access to the object's data then I'd just disable/mark/ignore the warning. If you want to modify the object via the pointer then that would be a bad idea.

[vanhuynh]

Thank you for your answer.

> Do you intend to be able to modify either the pointer value returned, or the data it references?
The data is intended to be read-only, e.g., used to calculate a checksum or sent over the wire.

To add some context, my difficulty is mostly because:
- Eventually I need to interface with C (POSIX) functions, which need raw pointers.
- Dynamic memory allocation on heap is not allowed.
I can't think of a solution satisfying these conditions using unique_ptr/shared_ptr. Feel free to suggest a solution if you have one .

> If you are returning a convenience pointer to const data itself then you need to declare as

Code:

const uint8_t* fn() const;

I totally agree.

> If you just want to reference read-only access to the object's data then I'd just disable/mark/ignore the warning.
Hopefully I can get a sign-off for this.

Kind regards,


kent.dorfman766

Hello,

Our team uses a static analysis tool for ASIL-B compliance. The tool warns about violation of rule A20-8-2/A20-8-3 when a non-owning pointer is returned from a function:

Code:

  template <uint64_t CAPACITY>
  class FixedCapacityBuffer {
      std::array<uint8_t, CAPACITY> buffer;
      uint64_t length;

  public:
      uint8_t* Data() const noexcept { return buffer.data(); } //////////////< Violation of rule A20-8-2/A20-8-3?

      // ...
  };

Code:

 
Rule A20-8-3: "A unique_ptr shall be used to represent exclusive ownership."
Rule A20-8-3: "A std::shared_ptr shall be used to represent shared ownership."

However, I do not want to express exclusive or shared ownership. Is the warning correct or a false-positive?

Do you intend to be able to modify either the pointer value returned, or the data it references? 
If you intend to be able to modify the objects internal buffer via the returned pointer then that is bad ju-ju.  If you are returning a convenience pointer to const data itself then you need to declare as

Code:

const uint8_t* fn() const;

But in some circles both would be considered "bad" since no guarantee that the pointer isn't referenced after the object itself is destroyed, thus the reason for the unique_ptr rule.

If you just want to reference read-only access to the object's data then I'd just disable/mark/ignore the warning.  If you want to modify the object via the pointer then that would be a bad idea.
[/quote]

[kent.dorfman766]

To add some context, my difficulty is mostly because:
- Eventually I need to interface with C (POSIX) functions, which need raw pointers.
- Dynamic memory allocation on heap is not allowed.
I can't think of a solution satisfying these conditions using unique_ptr/shared_ptr. Feel free to suggest a solution if you have one .

I spent the past three years doing similar for a commercial space program.  Unless you have the organizational power to disable specific warnings expect that most of your use of the POSIX system API will generate violations.  POSIX system API is not compatible with MISRA/AUTOSAR.

Also concentrate on inline C++ wrappers around the POSIX stuff so that you minimize the number of places where you have to justify the violations.  A lot will be gained with proper layered system design.

[misra cpp]

This code should not be reported as a violation of A20-8-2/A20-8-3, as these are about the explicit use of unique_ptr/shared_ptr, and not requiring their use in situations such as in the above example.

However, the code does violate A9-3-1 Member functions shall not return non-const “raw” pointers or references to private or protected data owned by the class.

We agree with the poster that replied “…concentrate on inline C++ wrappers around the POSIX stuff so that you minimize the number of places where you have to justify the violations.  A lot will be gained with proper layered system design.”