Version 1.0.1 Encode does not work as intended

[torbWaterLinked]

Describe the bug
Encode in version 1.0.1 does not zero-terminate the resulting byte array.

example:
non zero-ended
bytes: [1 2 6 0 0 1 1 8 192 11 0 198]
encoded: [4 1 2 6 1 6 1 1 8 192 11 2 198]

zero-ended
bytes: [1 2 6 0 0 1 1 8 192 11 0 198 0]
encoded: [4 1 2 6 1 6 1 1 8 192 11 2 198]

To Reproduce
Steps to reproduce the behavior:

1. Use any byte array
2. input it to Encode function with the v1.0.1 version
3. See that the result isn't zero-terminated

Expected behavior
Expect the Encoded byte array to be zero-terminated

[dim13]

This is actually desired behaviour.

For non-zero-terminated data, trailing zero is implied. See "COBS Syntax and Semantics" in documentation. Corollary there is no way to distinguish between implied and actual trailing zero in actual data while decoding.

Resulting encoded data shall have all zeros eliminated. See "COBS Syntax and Semantics" again. Zero value in encoded data is illegal. See Table 1.

If you need your encoded data to be zero-terminated (as meta-framing), feel free to append it after encoding.

PS: I would love to hear your use-case, and why you think trailing zero must be a part of encoded message.

[torbWaterLinked]

As a zero-terminated byte array is desired. I do propose that you return an error if it isn't zero terminated. As it stands now adding a zero will change the byte array inputted and a decoding of the encoded byte array won't return the correct byte array. We will change our code to accommodate it, but I still think it's prudent to change it to return an error when the input isn't properly formatted.

[pdgendt]

Bumped into this issue after spending a lot of time... IMO encoding shouldn't care about what is passed (NULL-terminated or not), and Decode should produce the output as was passed to Encode.

I've created my own version: https://github.com/pdgendt/cobs