Remove rule 58 from coding guidelines

[nashif]

Introduction

Problem description

see #89724 (comment)

Proposed change

Remove rule

[Thalley]

Question: If we remove a rule (e.g. 58), do we remove the rule number as well, or will the current rule 59 become rule 58?

[keith-zephyr]

I think the SonarQube error reported on #87450 is actually a bug in SonarQube.

The MISRA rule is explicitly for when array uses designated initializers.

   int32_t a1[ ]    = { [0] = 1 };    /* Non-compliant - probably unintentional to have single element */

But #87450 didn't specify array indexes using designated initializers.

	static const struct {
		int code;
		const char *str;
	} reason_strings[] = {
		{ WLAN_REASON_NO_REASON, "No reason specified" },
...

@jhedberg for visibilty.

[nashif]

hmm, i think it is hitting

MISRA C:2012, 8.11 - When an array with external linkage is declared, its size should be explicitely specified

which we do not have in our guidelines, but sonar combines the two: 9.5 and 8.11

[keith-zephyr]

hmm, i think it is hitting

MISRA C:2012, 8.11 - When an array with external linkage is declared, its size should be explicitely specified

which we do not have in our guidelines, but sonar combines the two: 9.5 and 8.11

PR #87450 declared a static array inside a function. So the external linkage of rule 8.11 shouldn't apply.

I'm not necessarily against removing rule 58, but I haven't seen an instance where this rule is causing a problem.

@simhein what are your thoughts on removing this rule?

[de-nordic]

I think this is intended to avoid errors like:

some_type some_array[] = { [0] = { init_0 }, [1] = { init_1}, [22] = { init_2 },  [3] = { init_3 } };

where you would end up with an array of 23 elements, while expecting 4. I guess that would get detected quickly?

[nashif]

hmm, i think it is hitting
MISRA C:2012, 8.11 - When an array with external linkage is declared, its size should be explicitely specified
which we do not have in our guidelines, but sonar combines the two: 9.5 and 8.11

PR #87450 declared a static array inside a function. So the external linkage of rule 8.11 shouldn't apply.

yeah, I was not referring to this PR, was talking in general, it seems the sonarqube rule does combine two MISRA rules, one which is in our guidelines, the other is not, so this is confusing.

I'm not necessarily against removing rule 58, but I haven't seen an instance where this rule is causing a problem.

@simhein what are your thoughts on removing this rule?

@keith-zephyr Simon is not active in the project any more. This is something we need to descide on collectively with input from the safety/security cmtes and maintainers in general.

[nvetrini]

Just as a data point, the Xen hypervisor project decided not to follow Rule 58 (i.e. MISRA C Rule 9.5) with roughly the same justification given by @de-nordic :

The possibility of committing mistakes by specifying an explicit dimension is higher than omitting the dimension.

which hasn't raised any concerns so far. If there are successive modifications to the same array specifying a size it is probably only going to increase the chance of introducing mistakes, rather than reduce it.

[keith-zephyr]

I agree with @nvetrini and @de-nordic - we should remove rule 58.