dagenix/libzbase32

libzbase32's Issues

Please add tests for the no_std variant

Looks like the mod tests sections in src/{encode,decode}_impl.rs both test the high-level interface, which requires std

that means that a test without the std feature will fail:

0 dkg@hos:…/libzbase32$ cargo --offline test --all-targets --no-default-features 
   Compiling libzbase32 v2.0.1 (…/libzbase32)
error[E0432]: unresolved import `super::decode`
   --> src/decode_impl.rs:264:9
    |
264 |     use super::decode;
    |         ^^^^^^^^^^^^^ no `decode` in `decode_impl`

error[E0432]: unresolved import `super::encode`
   --> src/encode_impl.rs:253:9
    |
253 |     use super::encode;
    |         ^^^^^^^^^^^^^ no `encode` in `encode_impl`

error[E0433]: failed to resolve: use of undeclared type `Vec`
   --> src/decode_impl.rs:268:26
    |
268 |         let mut buffer = Vec::new();
    |                          ^^^ use of undeclared type `Vec`

error[E0433]: failed to resolve: use of undeclared type `String`
   --> src/encode_impl.rs:257:26
    |
257 |         let mut buffer = String::new();
    |                          ^^^^^^ use of undeclared type `String`

Some errors have detailed explanations: E0432, E0433.
For more information about an error, try `rustc --explain E0432`.
error: could not compile `libzbase32` due to 4 previous errors
101 dkg@host:…/libzbase32$ 

If i decorate the two mod tests sections with #[cfg(feature = "std")] then i get a handful of warnings about unused items in src/test_data.rs -- and no tests run at all ☹

Seems like the right thing to do is to add tests for the low level api.

Take advantage of z-base32 disambiguation when encountering a 2 or a 0

In the z-base-32 specification, Phil Zimmermann wrote:

Our choice of confusing characters to eliminate is: `0', `l', `v', and `2'.  Our 
reasoning is that `0' is potentially mistaken for `o', that `l' is potentially 
mistaken for `1' or `i', that `v' is potentially mistaken for `u' or `r' 
(especially in handwriting) and that `2' is potentially mistaken for `z' 
(especially in handwriting).

If an l or a v arrives when decoding, we don't know what to do with it. But if a 2 arrives in the encoded form, we can presume it should have been a z, and if a 0 arrives, we can presume it should have been an o.

The decoding functions could be more lenient for 2 and 0, mapping them to z and o directly.

high-level API: simplify encoding a whole number of bytes

The high-level encode function is still slightly unergonomic for the common use case of encoding a whole number of bytes.

As far as i can tell, the only errors possible for encode are:

• bits doesn't match length of input
• total encoded value will exceed the ability to allocate RAM

For the common use case it would be nice to have something like:

pub fn encode_full_bytes(input: &[u8]) -> Result(String, ZBase32Error)

or even (treating memory allocation failures as unrecoverable errors):

pub fn encode_full_bytes(input: &[u8]) -> String

(this latter interface is offered by the popular zbase32 crate, so implementing it would make it easier for people to move from zbase32 to this implementation)