If you compare source-code version to English textual description of the same, you'll find source-code version actually much more readable and consice. So it's not a problem of C. It's problem of overcomplicated engineering.
explain with language syntax will be more easier than using code , int{pointer} i , int {pointer}i . pointer of int , and pointer of i . then with char *(*(*x[][8])())[] . char {pointer}({pointer}({pointer}x[][8])())[] . the rest will be understand as definition in C (each other language have different definition) . just like math programmer using syntax which is the field in linguistic to depict the property of system . because the programming community using english as major language so they inherit structure quite easy. it also the topic in CS back to 30 year ago . but that is not the tough one , because these code will be complied as binarry or machine code . if we change 2 basic these condition (mostly in OS or module)with new definition , the program will collapse. save you mind to real challange not definition .
A pointer consists of: 7, 9, 9, 9, 9, 9, 12. I.e. 7 bits unused, 12 bits for the physical offset in memory and the 9's are offsets into a page "tree" if you will . Most CPU's today only use four-level pages, so the top 16 bits (instead of 7) are unused - but Intel is starting to use five-level pages too. It's also why pages are 2^12 (4096) in size, and why large pages can be 2MB (2^(12+9)) and 1GB (2^(12+9+9)) respectively. You can cast a pointer to a number, and shift the bits into different values to clearly see how there's a clear pattern when you allocate memory etc.
Imo even better is actually dereferencing this madness. Worst I have seen in the wild, was to dereference was a pointer to an element in a list of pointers referencing to an element in a list of pointers referencing to an elemenr in a list of pointers referencing to a string. While "only" beeing a char***** understanding this madness is pure insanity. I _love_ Embedded Programming...
Next step is migrating to Godot cause you realize that Unity is not free and someday the greedy bosses behind the Unity company will come up with something to extract the most possible money from you and your project.
This is not the sort of code you read and understand. This is the sort of code you slowly build over the course of codifying your use case needs, then look back at a little while later and go like "goddammit if I want to change this I'll have to write it all over again so I know how it works" Also, this is a clear showcase of specialised LLM supremacy. If there's one domain they can understand better than any human, it's this
I have been working professionally with C for well over a decade. I know most of the ways it can bite. If I see any of these in production, I'm burning the codebase and walking away, and so should you.
