String-literals broken up into multiple lines

[avl (Andreas L.)]

I’ve got a case at hand, where there is a long string literal, broken up into parts with a backslash at eol. e.g.:

static const char *foo = 
"Lorem ipsum ... \
 blah blah ";

SonarQube tells me: Remove the LF characters or replace them with the escaped value "\n" and use string continuation.

I don’t want newlines to be part of the literal, I just want to avoid >100 chars long lines in the source.

[aalvarez (Alejandro Álvarez Ayllón)]

Hello @avl

I do not think it is an FP, but more like the wording of the rule is not clear. “Use string concatenation” means replacing your snippet with

static const char *foo = 
"Lorem ipsum ... "
" blah blah ";

Which is equivalent, and does not trigger the rule, since it is clearer what the intention of the code is (i.e. there is no invisible but meaningful control character).

[avl (Andreas L.)]

ok, string concatenation would solve it.

I still do not yet understand, how "...\ (and on next line) ..." would actually place any control characters into the string. Examining the strings of the compiled object seems to confirm my claim that no control char occurs in the string - am I missing other special cases?

Otoh., I fully understand, that literal tab-chars (and other control chars that really end up in the string) are addressed by the rule.

[aalvarez (Alejandro Álvarez Ayllón)]

@avl

Examining the strings of the compiled object seems to confirm my claim that no control char occurs in the string

True, '\n' does not end in the binary. The problem is more like

const char* foo = "this is a \tab"

vs

const char* foo = "this is a \
tab"

Are not the same thing. The control character on the source (\n) is meaningful but not (arguably) visible.

Likewise, the problem with tab is that

const char *foo = "lorem    itsum"

It is not immediately visible if there is a tab or four spaces. Hence, if it is a tab, it should be \t to be explicit.

So the spirit is more “what does another developer sees/hear(*)”, not so much what ends up on the binary.

(*) At least my system’s default screen reader reads "this is a \tab" as quote this is a backslash tab quote with and without a new line after the slash.

[avl (Andreas L.)]

Ok, I didn’t think as far as “screen-readers reading the source”.

Makes sense now, thanks!