MISRA Discussion Forums
A20-8-2 / A20-8-3 - Is returning a non-owning pointer always a violation? - Printable Version

+- MISRA Discussion Forums (https://forum.misra.org.uk)
+-- Forum: MISRA C++ (https://forum.misra.org.uk/forumdisplay.php?fid=18)
+--- Forum: AUTOSAR C++:2014 rules (https://forum.misra.org.uk/forumdisplay.php?fid=185)
+--- Thread: A20-8-2 / A20-8-3 - Is returning a non-owning pointer always a violation? (/showthread.php?tid=1636)

A20-8-2 / A20-8-3 - Is returning a non-owning pointer always a violation? - vanhuynh - 24-11-2022

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?

RE: A20-8-2 / A20-8-3 - Is returning a non-owning pointer always a violation? - kent.dorfman766 - 03-12-2022

(24-11-2022, 01:41 PM)vanhuynh Wrote: 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.

RE: A20-8-2 / A20-8-3 - Is returning a non-owning pointer always a violation? - vanhuynh - 13-12-2022

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 Big Grin .

> 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
(24-11-2022, 01:41 PM)vanhuynh Wrote: 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]

RE: A20-8-2 / A20-8-3 - Is returning a non-owning pointer always a violation? - kent.dorfman766 - 15-12-2022

(13-12-2022, 05:04 PM)vanhuynh Wrote: 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 Big Grin .

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.

RE: A20-8-2 / A20-8-3 - Is returning a non-owning pointer always a violation? - misra cpp - 27-10-2023

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.”