1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
|
# TODO
cppcodec is in pretty good shape already.
Here are a number of things I'd like to do still:
* Stuff in the GitHub issues list.
* Implement place-based single number codecs (as opposed to stream codecs) that
view the entire input string as a single number and therefore zero-extend
*to the left* to the next bit multiple (e.g. n*5 for base32, n*4 for hex).
We want this to implement odd hex decoding (e.g. 0xF rather than 0x0F) and
the other interpretation of Crockford base32. No use case seems to exist for
base64 because it's thankfully specified well enough to always encode
octet streams, not numbers.
* API idea: Specialize the encode(Result&, const T&) overload to for T = number
and use that to accept numbers without changing the interface. Not sure if
it's a good idea to switch to a place-based single number codec based on T.
* API idea: Instead of trying to fit both into the same interface, make a
separate interface just for numbers. No binary arrays, templates only on
the encoded side.
* Naming: Current plan is to name place-based single number variants as the
original variant name plus `_num` appended. Examples: `base32_crockford_num`,
`hex_upper_num`, `hex_lower_num`.
* Since we don't know the total number of symbols (could be ignored characters?)
we might have to **(a)** assume there is no whitespace (fail) or
**(b)** walk the source data twice, the first time for counting symbols and
the second time for putting them into their right spot in the byte.
* Investigate binary size considerations. See how well inline deduplication
works in popular linkers. I've had good experiences with boost::asio but
I don't know if those can translate to a codec library.
* See if binary size would be saved if std::vector<[unsigned] char> could
return a temporary raw_result_buffer instead of being passed down as itself,
for use cases where both std::vector and raw pointer calls are in use.
* Benchmark our performance against other libraries. We should be pretty fast
since cppcodec is avoiding unnecessary copies or object construction, but
we're also not doing any special vectorization or inline assembly. Plus it
would be nice to know that the compiler optimizes the inline function calls
well, instead of merely assuming it.
* More codec variants:
* binary - useful for debugging
* octal
* z-base32 might be interesting (and has some funky marginal-space-savings
options if your input length isn't octets), but doesn't appear any more
popular than Crockford base32. Pretty far down on the list.
* base64 variants from PEM (RFC 1421), MIME (RFC 2045) and UTF-7 (RFC 2152)
since they're popular and less strict than RFC 4648. Requires more
sophisticated generation of whitespace and ideally also checks whether
the whitespace is correctly located in the input string.
* Proquints? I'm not quite sure about how useful those are in real life.
* Checksums: Crockford base32 and RFC 6920 unpadded base64url define optional
checksums, OpenPGP base64 has a mandatory one. Supporting these would mean
a change to the API, potentially together with other options (but not
necessarily so).
* User options: I'm not too big on accepting invalid/non-conformant input,
but maybe somebody has a valid use case where they need to be more lenient
than one of the standards where the solution shouldn't be a new codec variant
but instead options for an existing variant? I'm not convinced that's a good
idea right now, but if you think it is then please make a point.
* We'll probably want some kind of unspecified whitespace acceptance for hex,
maybe there should just be a template version of cppcodec::hex for that
with ignored characters as the template.
* Crockford base32 allows hyphens as visual delimiter (ignored when decoding)
but doesn't specify
|
