Ken, this is excellent! As a matter of fact, it made my own home grown OTF checker crash (and in the middle of charstring #167 at that -- I need to check for integer overflows, methinks), so it is indeed a good stress test.

Are you aware of a similar font on which I could do tests for a CFF charstring parser?

I am glad to hear that this font could serve a useful purpose. For me, I dropped it into the OS (Mac OS X), and it is serving as a fallback font.

About your request, I would need to know more about what limits you're looking to test. Charstring length?

I would need to know more about what limits you're looking to test. Charstring length?

Uh, no (that maxes out at 64K - 1, IIRC). It wasn't a really well thought out question: after some more studying I don't think there is any requirement at all to be able to 'test charstrings'.
Either a charstring is syntactically correct (i.e. leading to a valid stream of numbers and operators, where each operator clears the stack as per Spec.5177, and does not exceed the implementation limits in there), or it may be considered "malformed", and then there is probably something wrong with the charstring generator that was used.

A charstring generator is what I'm attempting to code; and indeed, encoding of outlines is straightforward (all just syntax) but problems in the "semantics" of outlines are much harder to detect, avoid, and/or automatically solve: overlapping shapes (I don't think there is an actual rule against this, but I gather it's "seriously frowned upon"), renegade curves (where 3 or more curve data points are 0), and artefacts cause by rounding from floating point coordinates to the 1,000 Unit Fixed Square.

A fun project, nevertheless.

Let me expand a bit on that for interested lurkers.

The byte stream
00 00 01 80 00 0A

is invalid because 00 does not produce valid code. This one is better:
FF 00 01 80 00 0A

because the first 5 bytes translate in a floating point number: 1.5. The sixth byte translates into the opcode "callsubr", so this sequence correctly translates into
1.5 callsubr

... but a subr number must be an integer (it is a simple table based lookup). So this is still "wrong", but on a higher level. But even when we change this code into
F6 0A

which translates into
-1 callsubr

we cannot be sure if this is "correct". According to Adobe's Charstring Specification #5177, there is a limit of 10 nested callsubr calls, and there is no way we can check if this one is the eleventh without actually parsing the entire charstring.

Still, these checks can be done by a fairly basic program. More insidious are syntactically correct constructs such as
10 0 10 vlineto

or indeed
10 0 -10 vlineto

(I'm certain that's not allowed), or self-crossing:
2 1 -1 -2 hlineto

... which is where the fun starts for me :)