Yes I need people to test my text console based expression parser and see if they can get it to crash. Basically enter numeric expressions like the following: 3 (3) 3+(2*(6+1))-8*2 It will first validify the string and will say incorrect if the syntax is wrong. If the syntax is validified then it will attempt to parse the expression and output a final result. I basically want to see if anybody can get this to crash somehow or output the wrong result. You can get it here: http://studentweb.tulane.edu/~mconway/expression.zip

Why not just generate expressions for it? Add a few function level unit tests? Asking people to manually verify something as boring and simple as a parser for a BNF that is only a handful of productions in the first 2 pages of any compiler construction text seems to be a bit excessive.

Hmmm, it took me a bit of effort to do this.
Maybe I went about it the wrong way? For me it wasn't that trivial and somewhat complex although I at least thought I did it pretty elegantly with a nice parse tree system. Initially it crashed on a lot of cases but I think I ironed out most of them.

I am not using something like Bison or Flex so just using the production rules is not the extent of it in my case. And by generate expressions do you mean from the production rules. I want to see how well it handles incorrect expressions as well.

You will have to forgive me - I didn't mean to imply the creation of the parser was trivial, only that the breadth of the grammar is small. In fact since your productions would contain something along the lines of 'expr := expr + term' you would have had to deal with left recursion and thus manually removed the left recursion by expanding your productions or by writing a bottom-up parser. Either way - not a simple task.

Given that you have created code that is reasonably complex I honestly think that a good set of unit tests to test low-level functionality would be beneficial. Beyond that into blackbox testing it would be trivial to generate both correct and incorrect numerical expressions - which would be able to test many more cases then a few nerds getting bored after typing in a handful of expressions.

One way to generate expressions would be to build them, bottom up, from the productions (deviating from the productions to create incorrect expressions and check specific error messages) which wouldn't be that bad to create if you did, in fact, write a bottom-up parser. Otherwise an extended finite automata could create reasonable expressions (again deviating to create incorrect expressions) if you added paren counting (really a simplified pushdown automata).

Or just throw in random tokens - some are bound to actually be correct expressions if you let it run long enough ;)