For this C code: const char * a[ 4] = { " fred ", " bert " " harry ", " eric " }; Note missing "," on the bert line. gcc doesn't say very much: $ /home/dcb/gcc/results/bin/gcc -c -g -O2 -Wall -Wextra feb17f.cc $ Here is a recent clang doing something more useful: $ /home/dcb/llvm/clang1200rc1/bin/clang++ -c -g -O2 -Wall -Wextra feb17f.cc feb17f.cc:7:2: warning: suspicious concatenation of string literals in an array initialization; did you mean to separate the elements with a comma? [-Wstring-concatenation] " harry ", ^ feb17f.cc:6:2: note: place parentheses around the string literal to silence warning " bert " ^ 1 warning generated.
Having this warning would have saved me a lot of grief trying to hunt down a particular bug I remember having to deal with in the past; confirmed.
I usually write code that compiles warning free on both gcc and clang. I only noticed this difference between gcc and clang as a result of compiling the latest release of the tor browser. I thought it would be good to generalise it. I guess there must be some way to get both gcc and clang to emit all possible warning messages they can, then diff the two lists, to find out where one compiler could be enhanced. The strings command might be the way forward on this. I'd be happy to help with testing any prototype implementation. Interesting, my usual static analyser, cppcheck, has nothing to say also, so that's probably worth a bug report too.
Adding clang's name for this warning to the title for easier findability. Also this warning has found a few issues in GCC's own code; see here: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566749.html ...and here: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566750.html
Interestingly, I compiled fedora rawhide with clang and found a whopping 247 cases of this warning across 11 packages.