Rule 11.5 and char/string constants

[armand]

Hi,

Whilst testing my implementation of rule 4.2 with a simple example, I got a warning about rule 11.5. It is on the following simple example:

void main() {
char * x="abcd";
return;
}

that is automatically translated by CIL into the following C code, where one can notice a new cast.

void main() {
char *x;
x=(char *)"abcd";
}

the 11.5 warning concerns the assignment, where it complains that the attribute const has been lost.
Indeed, the rhs expression has type const char *, so this seems normal.

A correct writing would be:

void main() {
char *x;
char content[4]="abcd";
x=&content[0];
}
which does not generate the 11.5 warning as we have well typed the constant and assigned the first element's address into x.
BUT, now I get a warning about rule 9.2 explaining that I haven't a braced expression on the rhs of the assignement, to initialize the array!!

I can correct this by decomposing "abcd" into {'a','b','c','d''} which removes the last warning but gets tedious.

So my question is: does MISRA discourage programmers from using strings?

[Lundin]

Perhaps you get the warning because the array is too small: C strings are null-terminated. Correct code would be content[5] or content[]. Do you get the same warning if you write

char content[4] = {'a','b','c','d','\0'};

Apart from that bug, I don't think you should get any warning, though one can't really blame the tool vendor from generating it, as rule 9.2 doesn't actually mention strings at all. Perhaps some text should be added to 9.2 mentioning string initialization.

[armand]

The tool "vendor" is me, as I am developing a MISRA rules checker within a static analysis tool. So I'm trying to make it as compliant as possible with the MISRA C 204 rules.

If I write the assignment by decomposing the string into characters then I have no more 9.2 warning as the brackets are there.

I guess that rule 9.2 should distinguish the case of strings that are a shortcut for arrays of chars.

[misra-c]

Answering the points in turn:

1. Section 6.5.7 of the C90 Standard states that an array of character type may be initialised by a character string literal optionally enclosed in braces. The wording of Rule 9.2 does not cover this particular case but there is no reason to require the string literal be enclosed in braces and therefore no reason for a tool to produce a diagnostic. The rule will be updated in the next revision of the MISRA C Guidelines to make this clear.
   
2. Section 6.1.4 of the C90 Standard states that a character string literal behaves as an array of type char. It also states that the behaviour is undefined if a program attempts to modify a string literal. However, it does not make any statement about the const qualifier. Further, the C99 Rationale (admittedly not applicable to MISRA C:2004 but a useful source of guidance anyway) states that this was done intentionally. Therefore it is incorrect to assume that "abcd" has type const char *, even though it may behave as if it did. It follows that it is incorrect to issue a diagnostic against Rule 11.5 for
   
   Code:

   char * x="abcd";

As has been pointed out by Lundin, the code:

Code:

void main() {
char *x;
char content[4]="abcd";
x=&content[0];
}

is not equivalent. The array has 4 elements which contain the 4 characters from the string literal but there is no room for the null character to terminate the string. This is likely to give rise to problems if the array is treated as a string. The array either needs to be the same size as the string literal including the terminating character or the array size should be left unspecified in which case it will precisely the right number of characters.