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

[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]