Consider merging the functionality from crate "binary_macros" about data-encoding HOT 5 CLOSED

The functionality of binary_macros is exactly what I needed to load the signing keys for JSON web tokens. I am already using data-encoding to decode and encode JSON web tokens, so it would be nice from a consistency standpoint to know that the same implementation is used for the different sources of encoded data in my program.

+1 on merging.

from data-encoding.

Hi,

I am currently trying to finish v2. When it's done I could consider this for v2.1. In the meantime, just so that I understand better what it is about, could you provide me with examples and links to how and when this feature would be useful?

My current understanding is that it permits to decode encoded strings from files, environnement variables, or constant strings at compile time. At first glance this looks outside the scope of data-encoding in the sense that reading files or environnement variables is something orthogonal to the purpose of data-encoding. The compile-time aspect could be considered, but there are already solutions like lazy_static (which is not really compile-time), build.rs, and hard-coded literals. I would prefer to make those tools easier to use, rather than bake their use in data-encoding.

I am actually currently facing such decisions for v2.0.0-rc.2 to allow users to define custom encodings as global variables, with either lazy_static, build.rs, or hard-coded literals (with const fn).

from data-encoding.

Thanks for asking! First of all, my motivation for the crate was that I wanted to bundle a compile-time pepper (in addition to the normal salt) for hashing passwords. It has also other uses, but the main ones I've come up with are bundling crypto stuff like keys, secrets and certs at compile time, while having the file as a nice base64 or hex format, instead of a binary.

Because I'm bundling the data at compile time, a macro is necessary. Of course, there exists macros for bundling binary data at compile time, but if you also want to decode encoded data, it's better to do the decoding at compile time too. The reason is simple: in the case your data is borked, you get the error messages earlier (during compilation, not after deployment) and you get the assurance that at least that part of the app is fine.

So, one could bundle the raw data using the macros from the std, but they would still be in an ASCII format. Using this library as a macro is necessary if you want to end up with a binary with the ASCII already decoded into the final binary data.

from data-encoding.

Hi Pyry,

I created #15 which adds a data-encoding-macro crate with the following macros:

• A set of macros to define a compile-time byte array using common encodings (base64, base32, hexlower, etc.) to decode a string literal
• A generic decode macro that does the same for custom encodings
• A new_encoding macro to define a compile-time custom encoding

The main differences that I can see with binary_macros are:

• It requires a nightly compiler (I should take a look at proc-macro-hack when I get time)
• It defines the compile-time byte array directly instead of defining it in a hidden scope and returning a reference

If you have some time, I could use your input before submitting. Here are the two files that describe how to use those macros:

• https://github.com/ia0/data-encoding/pull/15/files#diff-f87df0c0c8471eddc7a5449f877b1f8d
• https://github.com/ia0/data-encoding/pull/15/files#diff-7d13849c3e2602b35ad820d75df23d34

I'll probably submit this week-end and do further modifications if needed.

Thanks,
Julien

from data-encoding.

I ended up closing the differences with the binary_macros crate:

• There is now a "stable" feature (enabled by default) relying on proc-macro-hack to permit usage with a stable compiler.
• The simple macros return a slice (there is still a macro to build an array, but only in nightly).

from data-encoding.