Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
A12-1-1 - Does it apply to POD structs?
#1
Hi,

Does A12-1-1 apply to POD structs? Example:

Code:
struct Foo
{
  int x;
  int y;
};

The members of `Foo` are by default uninitialized. Does A12-1-1 require `Foo` to explicitly initialize its members, like this?

Code:
struct Foo
Code:
{
Code:
  int x{};
Code:
  int y{};
Code:
};


Please note that the above change has some implications, namely that `Foo` is no longer trivial. As such, compilers will warn about performing `memcpy` operations on them. This is a problem for serializer/deserializer type of code.

Thanks!
Reply
#2
found this in the parasoft docs...reposting without permission. Dodgy 


All member variables should be initialized in constructor [AUTOSAR-A12_1_1-b]



DESCRIPTION


Constructors of 'class' and 'struct' should initialize all member variables.

The rule checks if a member variable is initialized:
- in constructor initialization list
- inside body of constructor
- inside body of function called from constructor (three levels of nested
  function's calls are checked)
- directly in class (C++11).

If there is no constructor at all a violation is reported for 'class' only.
You can enable INIT-15 to get a violation for 'struct' too.

See also: INIT-10, INIT-14, INIT-15, MISRA-030



NOTES


The rule assumes that member variable might be initialized
by passing its non-const pointer to an external function.

Member variables which are static or have class or struct type are ignored.
Static variables should not be initialized in constructor.
Class/struct variables are assumed to be initialized by their own constructors.

If in constructor is called default copy assignment operator,
then the rule assumes that all member variables are initialized.

If in constructor is called a member function from the current class with
non-accessible body, then this rule assumes that all member variables are
initialized.



BENEFITS


Prevents reading from uninitialized variables.






Reply
#3
Thanks for the snippet! I experience the same with static analyzers, they split into multiple diagnostics to allow for a finer level of control and specific project deviations.
Reply
#4
The intended reading of the rule is ‘if a class has a user-declared constructor, then ….’.  As a POD struct cannot have a user-declared constructor (that would stop it being POD), the rule doesn’t apply.
Posted by and on behalf of
the MISRA C++ Working Group
Reply
#5
Thank you for the clarification!
Reply
#6
Thread closed
Posted by and on behalf of
the MISRA C++ Working Group
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)