Weird string generated in QuickCheck

Question

I have a small Parsec program which I test using a QuickCheck script that generates an input file and an intended parse in parallel.

My test usually run the 100 tests fine, but then suddenly as I was casually testing something, they failed with a very large (600,000 chars) counter example. When I found out the source of the error, I got very confused:

\ETX\NUL\202&Hxv4\an3z\244\143\222\RS\236\n\150K

QuickCheck had apparently generated the above string for a variable name, even though I only use alphaNum, underscore and whitespace in my program.

Can you see any reason why the above sequence could arise? Could it be an overflow error somewhere? Or QuickCheck running tempoarily out of memory and writing a debug message?

I'm very sorry. It turned out I did actually have a condition that could create general strings. It was just very rare. Should I delete the question? — Thomas Ahle, Nov 12 '13 at 11:37
Nope, Just leave it but consider adding code so others can see what's going on — daniel gratzer, Nov 12 '13 at 12:40

score 2 · Accepted Answer · answered Oct 31 '13 at 17:35

This could be a false positive, but if the parsec parsers accept anything which match the regex character class for alphanumeric, then stuff which is unicode could also be generated. String doesn't support UTF8 encoded unicode, but Data.Text does.

A quick test in ghci (running Data.Text.IO.putStrLn . Data.Text.pack $ "\ETX\NUL\202&Hxv4\an3z\244\143\222\RS\236\n\150K") gives
Ê&Hxv4n3zôÞì K

Which almost looks like it matches what you requested, except for that ampersand. Perhaps I'm wrong, in which case I'm sure someone will correct me.

If anyone knows why that ampersand was generated, I'd like to know — Squidly, Nov 01 '13 at 09:43

Weird string generated in QuickCheck

1 Answers1