clang-format update (19 -> 20)

[zyv]

I've noticed that with a new Fedora release, the new Fedora 42 container is used, which has clang-format==20.*. It introduced some changes, but I think they are good ones.

I have my local clang-format pinned to 19, but I can easily upgrade and update the website:

https://midnight-commander.org/coding-style/

Alternative is to pin it in the CI. But I think it's not too bad that we have an update, and we can leave it as is and move to 20.

What do you think? @aborodin

[zyv]

I have updated the indentation in befa9a0 so that all branches can be rebased and updated the website:

MidnightCommander/website@3f3dee5

Unfortunately, the master build still fails with newer clang:

find.c: In function 'find_rotate_dash':
find.c:1223:42: error: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (5 chars into 4 available) [-Werror=unterminated-string-initialization]
 1223 |     static const char rotating_dash[4] = "|/-\\";
      |                                          ^~~~~~~

Will have to look into it... /cc @aborodin

[zyv]

I have pinned the clang-format version to 20.1.0 in the CI, so it turns green again, and I suggest we update it manually when we want to migrate to the next version.

[aborodin]

Unfortunately, the `master` build still fails with newer `clang`: ``` find.c: In function 'find_rotate_dash': find.c:1223:42: error: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (5 chars into 4 available) [-Werror=unterminated-string-initialization] 1223 | static const char rotating_dash[4] = "|/-\\"; | ^~~~~~~

Yes, rotating_dash isn't a string, it is just an array of chars. To pacify the compiler, we can define it as `static const char rotating_dash[5] = "|/-\\";` or `static const char rotating_dash[4] = { '|', '/', '-', '\\' };` but I'm not sure about 2nd case.

[zyv]

The first approach is wrong, and the second approach works, but I think it has the disadvantage that you don't get the protection against using string APIs.

It seems that the best solution is to use a correct compiler attribute, as is done in many other projects (Kernel, VirtualBox, WireGuard, etc.)

I have opened a PR:

#4690

[zyv]

For now, I have pinned it in our CI. We should then try updating it manually :-/