True

also in C99 you are allowed to create arrays in runtime with no predefined size

and this is very bad practice, because you risk silently blowing up the stack if the size is very large.
VLAs (variable length arrays) are bad. if you know that the length will always be below some reasonably low value (say 4096 or 8192), then you should be using this value as the compile-time length. if the length can be arbitraryly long, then you should allocate on the heap with malloc()&co, and check if the returned pointer is NULL. VLAs are stack-allocated and unsafe, because there is no well-defined way to know if the stack has enough space for your array at runtime. if your big array smashes the stack, anything can happen. if you are lucky, your program will crash, but you could also be overwriting other memory and make the program completely unpredictable.

to make matters worse, VLAs are an optional feature, and in particular they are not available on Microsoft Visual Studio C

pointers to VLA, on the other hand, are an entirely different story because they can be heap-allocated, and they have tremendously improved the C language by allowing constructs that were impossible to express before

Thank you for the comments!

I continously try to optimize every solutions to the maximum readability, maintainabilty and efficiency.
If you find out that any of my solutions can be better, please let me know, I appreciate it ;).

True, it's a test-driven solution.

in fact it's not even the case on Codewars, which runs on x64 Linux: size_t is unsigned long. The data model is LP64 aka 4/8/8 : sizeof(int) == 4, sizeof(long) == sizeof(long long) == 8