string literals and strcat

Question

I am not sure why strcat works in this case for me:

char* foo="foo";

printf(strcat(foo,"bar"));

It successfully prints "foobar" for me.

However, as per an earlier topic discussed on stackoverflow here: I just can't figure out strcat

It says, that the above should not work because foo is declared as a string literal. Instead, it needs to be declared as a buffer (an array of a predetermined size so that it can accommodate another string which we are trying to concatenate).

In that case, why does the above program work for me successfully?

String literals are immutable. You can't modify it. Any attempt to modify string literals can lead to **undefined behaviour** of the program. When there is UB, you can get either expected or any unexpected results. — haccks, Jul 10 '18 at 08:17
Out of curiosity, what compiler/platform are you using? Older compilers often just left string literals in writable memory (which *is* standard conformant, although quite a trap, as modifying them still led to "interesting" results) which would explain the behavior. The same applies for current-day compilers on platforms without memory protection. — Matteo Italia, Jul 10 '18 at 08:21
Even if `foo` was writable, it can't be concatenated to. Consider trying to concatenate to `char foo[] = "foo";`. Unlike `char foo[42] = "foo";` there is no memory available. — Weather Vane, Jul 10 '18 at 08:25
@WeatherVane read the question. He's linking to another questions where that is exactly the topic of discussion. So this is not the topic of this question. — JHBonarius, Jul 10 '18 at 08:28

gsamaras · Accepted Answer · 2018-07-10T08:24:18.917

This code invokes Undefined Behavior (UB), meaning that you have no guarantee of what will happen (failure here).

The reason is that string literals are immutable. That means that they are not mutable, and any attempt of doing so, will invoke UB.

Note what a difficult logical error(s) can arise with UB, since it might work (today and in your system), but it's still wrong, which makes it very likely that you might miss the error, and get along as everything was fine.

PS: In this Live Demo, I am lucky enough to get a Segmentation fault. I say lucky, because this seg fault will make me investigate and debug the code.

It's worth noting that GCC issues no warning, and the warning from Clang are also irrelevant:

p

rog.c:7:8: warning: format string is not a string literal (potentially insecure) [-Wformat-security]
printf(strcat(foo,"bar"));
       ^~~~~~~~~~~~~~~~~
prog.c:7:8: note: treat the string as an argument to avoid this
printf(strcat(foo,"bar"));
       ^
       "%s", 
1 warning generated.

@JHBonarius but that was in the other question. So this is not the topic of this question. ;p — Weather Vane, Jul 10 '18 at 08:33

Matteo Italia · Answer 2 · 2018-07-10T09:17:28.427

String literals are immutable in the sense that the compiler will operate under the assumption that you won't mutate them, not that you'll necessarily get an error if you try to modify them. In legalese, this is "undefined behavior", so anything can happen, and, as far as the standard is concerned, it's fine.

Now, on modern platforms and with modern compilers you do have extra protections: on platforms that have memory protection the string table generally gets placed in a read-only memory area, so that modifying it will get you a runtime error.

Still, you may have a compiler that doesn't provide any of the runtime-enforced checks, either because you are compiling for a platform without memory protection (e.g. pre-80386 x86, so pretty much any C compiler for DOS such as Turbo C, most microcontrollers when operating on RAM and not on flash, ...), or with an older compiler which doesn't exploit this hardware capability by default to remain compatible with older revisions (older VC++ for a long time), or with a modern compiler which has such an option explicitly enabled, again for compatibility with older code (e.g. gcc with -fwritable-strings). In all these cases, it's normal that you won't get any runtime error.

Finally, there's an extra devious corner case: current-day optimizers actively exploit undefined behavior - i.e. they assume that it will never happen, and modify the code accordingly. It's not impossible that a particularly smart compiler can generate code that just drops such a write, as it's legally allowed to do anything it likes most for such a case.

This can be seen for some simple code, such as:

int foo() {
    char *bar = "bar";
    *bar = 'a';
    if(*bar=='b') return 1;
    return 0;
}

here, with optimizations enabled:

VC++ sees that the write is used just for the condition that immediately follows, so it simplifies the whole thing to return 0; no memory write, no segfault, it "appears to work" (https://godbolt.org/g/cKqYU1);
gcc 4.1.2 "knows" that literals don't change; the write is redundant and it gets optimized away (so, no segfault), the whole thing becomes return 1 (https://godbolt.org/g/ejbqDm);
any more modern gcc choose a more schizophrenic route: the write is not elided (so you get a segfault with the default linker options), but if it succeeded (e.g. if you manually fiddle with memory protection) you'd get a return 1 (https://godbolt.org/g/rnUDYr) - so, memory modified but the code that follows thinks it hasn't been modified; this is particularly egregious on AVR, where there's no memory protection and the write succeeds.
clang does pretty much the same as gcc.

Long story short: don't try your luck and tread carefully. Always assign string literals to const char * (not plain char *) and let the type system help you avoid this kind of problems.

string literals and strcat

2 Answers2