CertC-STR10

Do not concatenate different type of string literals

Required inputs: IR

According to MISRA 2008, concatenation of wide and narrow string literals leads to undefined behavior. This was once considered implicitly undefined behavior until C90 [ ISO/IEC 9899:1990]. However, C99 defined this behavior [ ISO/IEC 9899:1999], and C11 further explains in subclause 6.4.5, paragraph 5 [ ISO/IEC 9899:2011]:

In translation phase 6, the multibyte character sequences specified by any sequence of adjacent character and identically-prefixed string literal tokens are concatenated into a single multibyte character sequence. If any of the tokens has an encoding prefix, the resulting multibyte character sequence is treated as having the same prefix; otherwise, it is treated as a character string literal. Whether differently-prefixed wide string literal tokens can be concatenated and, if so, the treatment of the resulting multibyte character sequence are implementation-defined.

Nonetheless, it is recommended that string literals that are concatenated should all be the same type so as not to rely on implementation-defined behavior or undefined behavior if compiled on a platform that supports only C90.

Noncompliant Code Example (C90)

This noncompliant code example concatenates wide and narrow string literals. Although the behavior is undefined in C90, the programmer probably intended to create a wide string literal.

wchar_t *msg = L"This message is very long, so I want to divide it "
                "into two parts.";

Compliant Solution (C90, Wide String Literals)

If the concatenated string needs to be a wide string literal, each element in the concatenation must be a wide string literal, as in this compliant solution:

wchar_t *msg = L"This message is very long, so I want to divide it "
               L"into two parts.";

Compliant Solution (C90, Narrow String Literals)

If wide string literals are unnecessary, it is better to use narrow string literals, as in this compliant solution:

char *msg = "This message is very long, so I want to divide it "
            "into two parts.";

Risk Assessment

The concatenation of wide and narrow string literals could lead to undefined behavior.

Rule	Severity	Likelihood	Remediation Cost	Priority	Level
STR10-C	Low	Probable	Medium	P4	L3

Related Guidelines

MISRA C++:2008

Rule 2-13-5

Bibliography

[ ISO/IEC 9899:2011]

Section 6.4.5, "String Literals"

Excerpt from SEI CERT C Coding Standard: Rules for Developing Safe, Reliable, and Secure Systems (2016 Edition) and SEI CERT C Coding Standard [https://cmu-sei.github.io/secure-coding-standards/sei-cert-c-coding-standard/recommendations/characters-and-strings-str/str10-c], Copyright (C) 1995-2026 Carnegie Mellon University. See section 9.4. "3rd-Party Licenses" in the documentation for full details.

Possible Messages

Key	Text	Severity	Disabled
mixed_string_concatenation	Concatenation of mixed string encodings	None	False
narrow_wide_concat	Concatenation of narrow and wide string literal	None	False

Options

• This rule shares the following common options: exclude_in_macros, exclude_messages_in_system_headers, excludes, extend_exclude_to_macro_invocations, includes, justification_checker, languages, post_processing, provider, report_at, severity

• The following places define options that affect this rule: Stylechecks, Analysis-GlobalOptions

cpp11_mode

cpp11_mode : bool = False

Use rules as defined in the C++11 standard. If false, only L and unprefixed literals are reported. If true, prefixes of length two and unprefixed literals are conforming; but additionally, mixed_string_concatenation compiler messages are reported.

 

report_all_prefix_differences

report_all_prefix_differences : bool = False

Report all prefix difference (i.e. do not exclude those with and without cpp11_mode).