| Age | Commit message (Collapse) | Author |
|---|
|
Often the decode functions return a function_clause error, but not
always, and the errors have not been consistent between modifications
of the base64 module.
Now the errors are returned as they happen--no attempt to make them
look nice is done. The alternative, to ensure that, for example,
{badarg, Culprit} is always returned upon bad input, was deemed
pointless.
|
|
Using /bits instead of /binary is faster when constructing binaries.
|
|
It is sometimes faster to use binary_to_list on input, at least when
not considering time for garbage collections. The three functions all
return a list, and the temporary list created by binary_to_list should
be reclaimed very fast. The implementation from before is thus kept.
|
|
A few test cases with zeroes are added. They were not handled correctly
before.
The access of DECODE_MAP is moved into the inlined function b64d, for
symmetry.
The function b64e is also inlined. The speed-up is small, but
measurable.
Note: encode(List), decode(List) and mime_decode(List) no longer call
list_to_binary. This can break code that calls the functions with
I/O-lists as input.
|
|
|
|
|
|
|
|
|
|
Symptom: Throughput of base64:mime_decode/1 significantly lower than
base64:decode/1.
Problem: tail_contains_more/2 prevents compiler from delaying creation
of sub binaries.
Solution: Restructure mime_decode_binary/2 to use binary matching best
practices from the Efficiency Guide.
See ERL-366
|
|
|
|
|
|
|
|
The type ascii_string() in the base64 module has been corrected.
The type file:file_info() has been cleaned up.
The type file:fd() has been made opaque in the documentation.
The type nodes() has been removed from erl_bif_types.erl.
|
|
|
|
|
|
Implement the 'MAY' clauses from RFC4648 regarding the pad character
to make mime_decode() and mime_decode_to_string() functions more
tolerant of badly padded base64. The RFC is quoted below for easy
reference.
RFC4648 Section 3.3 with reference to MIME decoding:
Furthermore, such specifications MAY ignore the pad character, "=",
treating it as non-alphabet data, if it is present before the end of
the encoded data. If more than the allowed number of pad characters
is found at the end of the string (e.g., a base 64 string terminated
with "==="), the excess pad characters MAY also be ignored.
|
|
|
