On 13 December 2017 at 01:23, Ian Lance Taylor <i...@golang.org> wrote: > On Tue, Dec 12, 2017 at 3:13 PM, Jeffrey Goldberg <j...@agilebits.com> wrote: >> >>> On Dec 12, 2017, at 9:00 AM, Ian Lance Taylor <i...@golang.org> wrote: >> >>> DecodedLen is supposed to be applied to the length of the encoded >>> data. RFC 4648 says that the encoded data must be padded to be a >>> multiple of 8 bytes. >> >> Yet encoding/hash32 defines a NoPadding constant, the code is filled >> with tests for whether the padding has been set to NoPadding, and the package >> docs make reference to setting things with NoPadding. > > Yes. But even with the no padding case, it is impossible to have an > encoded length of a single byte (I tried to say that in a bit of the > message that you didn't quote). And I hope we can all agree that > `DecodedLen` returns the correct value when called with an argument of > 2 when `padChar == NoPadding`. So we are only talking about the value > 1, which I assert is impossible in a valid base32 encoded string with > no padding.
Looking at http://philzimmermann.com/docs/human-oriented-base-32-encoding.txt, it seems that zbase32 allows the encoder and decoder to agree on the number of bits transmitted, so if you're encoding 5 bits or less, you can use a single encoded character. ISTM that this difference is probably justification enough to make a new zbase32 package rather than using encoding/base32 directly. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
