parsnip: Revisiting null-termination

[lambdadog]

I'm working my way through the implementation of parsnip right now and something I've begun to wonder is whether using a null-terminated bytevector internally is actually the best choice. It seems as if using the end address to determine if the input has ended would actually be better, from everything I can see. Realistically, this would probably involve adding the unboxed end address to the Result tuple so it ends up register packed for the sake of quick comparisons.

I suspect this would perform approximately the same as the current version and would allow parsnip to be used for parsing binary data, which is one of its current limitations.

Is there a reason that you reached for checking for the null terminator rather than using the end address when you already grab the end address during the construction of Base? I'm interested in forking and potentially implementing this more slice/iovec-based design, and potentially upstreaming if you'd be interested in that, but if you already decided against this design for a compelling reason I'd prefer to fail early rather than implementing it all only to then discover an issue.