On Sat 2019-05-11 20:45:59 -0600, David Bremner wrote:
> To the best of my understanding, this original behaviour was what
> Carl's homebrew parser produced. With commit 86f89385 Austin switched
> to using GMime (2.6). This produced arguably worse results, but since
> the input was bad, we could live with it. Now with GMime 3.0 we are
> getting the original results again, and there is no reason to consider
> this test broken.

this works for me.  I reviewed this earlier and tried to understand why
one ugly representation of invalid data was any worse than the other
ugly representation of invalid data. :P

It'd be great if someone wants to propose a principled way to handle
this invalid input, but just keeping the "broken" test around isn't a
good way to track that problem.

Please merge!

       --dkg