Expect separator after null byte during encoding (v0.2)

[SebbyLaw]

Currently the spec does not have the separator occuring after null bytes encoded to bottom. Below is a list of implementations that must be updated to follow this encoding change. Decoding should not need to be changed, as long as it already followed the spec.

Implementation	Encode Compliant	Decode Compliant
spec (README)
bottom-as
bottom-bash
bottom-c
bottom-d
bottom-dart
bottom-dotnet
bottom-ex
bottom-go
bottom-go-bindings
bottom-hs
bottom-hy
bottom-java
bottom-lua
bottom-matlab
bottom-php
bottom-py
bottom-py-bindings
bottom-rb
bottom-rs
bottom-swift
bottom-web
bottom-webextension
bottom-wl
bottom-workers
bottom-x86
oneline-bottom-py
power-bottom

Also see: #2, bottom-software-foundation/bottom-rs#8, bottom-software-foundation/bottom-go#1

[nihaals]

Maybe this should be changed into a table just so both encode and decode can be validated? Null byte was something I saw was ignored in a lot of implementations so it's possible some have a compliant encode but not a compliant decode.

[nihaals]

Here's a partial table:

Implementation	Encode compliant	Decode compliant
bottom-bash	​	​
bottom-c	​	​

Source

| Implementation | Encode compliant | Decode compliant |
|---|---|---|
| bottom-bash | <ul><li>- [ ] ​</li></ul> | <ul><li>- [ ] ​</li></ul> |
| bottom-c | <ul><li>- [ ] ​</li></ul> | <ul><li>- [ ] ​</li></ul> |

Note there are zero width spaces

[nihaals]

It might also be worth adding the version tested
That also means you can differentiate between implementations that have been verified to be noncompliant and implementations that haven't been checked yet

Without a standard testing suite it's hard to get automated testing on all of them, so it could also be possible that an implementation changes from being complaint to noncompliant, so logging versions could help with being clear about what was tested (although tracking changes after an implementation has become completely compliant is probably out of scope for this issue)

[SebbyLaw]

I've added the table. Decode is assumed not compliant until I review it or someone reviews it for me.

It might also be worth adding the version tested
That also means you can differentiate between implementations that have been verified to be noncompliant and implementations that haven't been checked yet

Without a standard testing suite it's hard to get automated testing on all of them, so it could also be possible that an implementation changes from being complaint to noncompliant, so logging versions could help with being clear about what was tested (although tracking changes after an implementation has become completely compliant is probably out of scope for this issue)

Out of the scope of this issue imo.

[elldritch]

FYI, null byte encoding works fine for bottom-hs, which has always encoded separators after null bytes.

For evidence:

• Here's the encoding logic for null bytes: https://github.com/bottom-software-foundation/bottom-hs/blob/f86c1fc88a772eb8a91469deea5b7df0b6cc2f76/src/Data/Encoding/Bottom.hs#L144
• Here's a test case: https://github.com/bottom-software-foundation/bottom-hs/blob/f86c1fc88a772eb8a91469deea5b7df0b6cc2f76/test/Main.hs#L40
• Here's a passing run of that test: https://github.com/bottom-software-foundation/bottom-hs/runs/2251350907

a standard testing suite

You could build one of these pretty easily by adapting the bottom-hs test suite to accept adapters for other CLIs. It uses both the bottom-rs tests as well as randomized property-based testing via QuickCheck.

[SebbyLaw]

Thanks! I've updated the table to match