The program uses a table-driven lexer and a hand-written, shift-reduce parser. No external dependencies apart from the standard library.
As per the screenshot, “arr” is an array of 4 elements. Consequently, “arr[0]” is an array of 8 elements. Then, “arr[0][0]” is a pointer. And so on, until we arrive at the specifier-qualifier list.
P.S. Please add a license for your code.
[1] https://tree-sitter.github.io/
[2] https://github.com/rizinorg/rizin/tree/dev/librz/type/parser
TL;DR: you declare a variable in C _in exactly the same way you would use it:_ if you know how to use a variable, then you know how to read and write a declaration for it.
https://eigenstate.org/notes/c-decl https://news.ycombinator.com/item?id=12775966
In other words, the precedence of operators in a declaration have exactly the same precedence as in its use.
int x, *p, arr[5], fn(), (*pfn)();
Using x, or dereferencing p, or subscripting the array arr, or declaring a function that can be called with fn, or dereferencing the function pointer pfn then calling it, all these things would produce an int.It's the intended way to read/write declarations/expressions. As a consequence, asterisks ends up placed near the identifiers. The confused ones will think it's a stylistic choice and won't understand any of this.
If you want to typedef a function pointer, make a completely ordinary function declaration, then slap 'typedef' at the beginning, done. This does require you to do "foo_func *f" instead of "foo_func f" when declaring variables, but that is just clearer imo.
typedef int foo_func(int); // nice
typedef int (*foo_func)(int); // why?You know you don't always have to use things as they were intended?
> The confused ones will think it's a stylistic choice and won't understand any of this.
Well, I've written it both ways, and the compiler never seems to mind. :)
Maybe I should start putting space on both sides of the asterisk; seems like it would be a good way to annoy even more people.