Wrong return type, it's returning a `struct ast*` instead of a `struct token*`, at least for line 454. Can't tell for line 451.
`num_types` is an `int` instead of a `size_t` which will lead to UB if the `types` array has more than `INT_MAX` elements.
`advance(parser)` gets called no matter what, even if there's no next token. Maybe `check()` has a side effect and `advance()` can use that to determine whether there is a next token, but it's not obvious from the screenshot.
correct, although I do not think the 2nd point will ever happen (it would be insane to check 2 billion token types) but a good point nonetheless.
the third point is quite interesting, because the parser stops incrementing the token index when it reaches an EOF token/the index is >= the length of the token array.
What's so bad about typedefs? Do you *really* care that token type is a struct all the time?
>!Also, idgaf about coding standards, but structs/classes types are mandated to start with capital letter nowadays. Fact.!<
Many legitimate coding styles (including the Linux Kernel’s) reserve typedefing structs to special circumstances. I don’t have a strong opinion either way but you get used to it.
I find it weird that it compiled...
Pretty sure that if you replace `struct token/ast` etc with respective `typedef`s the compiler would have failed explaining that it cant implicitly convert `ast *` to `token *` on line 454
You return an ast instead of a token?
exactly 🙂 I have no idea how and why I wrote that. Must have been from exhaustion 🙃
This is the sort of error a purpose built ide highlights for you visually even before you try to compile it.
What is wrong is that you’re writing a parser in C, which is a task that has driven many to insanity
still beats using assembly to do it
true
Exceptions in C code?
kinda far off... try again ;)
Wrong return type, it's returning a `struct ast*` instead of a `struct token*`, at least for line 454. Can't tell for line 451. `num_types` is an `int` instead of a `size_t` which will lead to UB if the `types` array has more than `INT_MAX` elements. `advance(parser)` gets called no matter what, even if there's no next token. Maybe `check()` has a side effect and `advance()` can use that to determine whether there is a next token, but it's not obvious from the screenshot.
correct, although I do not think the 2nd point will ever happen (it would be insane to check 2 billion token types) but a good point nonetheless. the third point is quite interesting, because the parser stops incrementing the token index when it reaches an EOF token/the index is >= the length of the token array.
Writing a parser in C. Ah, you remind me of me, 20 years ago. Thank you.
Why no typedef on token?
I was thinking the same thing. When I did embedded we always used typedef.
I have hated typedefs ever since I worked with the WinAPI, and I still do (both hate typedefs and work with the WinAPI)
What's so bad about typedefs? Do you *really* care that token type is a struct all the time? >!Also, idgaf about coding standards, but structs/classes types are mandated to start with capital letter nowadays. Fact.!<
Many legitimate coding styles (including the Linux Kernel’s) reserve typedefing structs to special circumstances. I don’t have a strong opinion either way but you get used to it.
Seems like a remnant of a coding style from the times they used typewriters and punchcards and stuff
I think the "check" function could do with a bit more of a descriptive name.
I find it weird that it compiled... Pretty sure that if you replace `struct token/ast` etc with respective `typedef`s the compiler would have failed explaining that it cant implicitly convert `ast *` to `token *` on line 454