[bitm0de]

That code could be heavily cleaned up. You could group similar constructs that use the same grammar for expressions and create proper parsing tables to ease the process of using lexical analysis + parsing. Reduce the number of hardcoded numbers you're using, and make more appropriate macros, instead of:

Code:

#define ERR() free(tmp); error = true; return 0;

If you read up on why people use do{}while(0), you'll see many discussions on this. I don't know why a macro like ERR() should free stuff on the heap, and return 0 though, that's not really self-documenting, and the way it's written you restrict it from being placed in a lot of locations in code.

I read through some of the other threads too but I didn't see any mention of LALR or LR(1) or any of the other common parsers. If anyone is really serious about programming they should look into how those work. Not only do they help you reduce boilerplate code if you implement them properly, but they're also far more scalable than the manual parsing you're doing on a 1-to-1 per syntax basis.

As a sidenote, 512 being a multiple or power of 2 is not the best number for CPU cache performance. There's a good PDF somewhere written by someone that explains a few things about this number, but I'm sure you can find it with a simple google search. I would've just chosen a PAGE size personally.

If you posted this on github I'm sure others could help you clean it up a bit too.. Real parsers aren't written like this because this will never scale. It is about tokens but you don't create any hierarchy of tokens anywhere in that code; no trees, just string manipulation and conversions.