| 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.
|
|
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.
|
|
|
|
|
|
* valgrind needs lots of time
|
|
|
|
|
|
Either rely on the default 30 minutes timetrap, or set the timeout
using the supported methods in common_test.
|
|
|
|
Refactor roundtrip/1 into 4 test cases that can be run in parallel.
Assuming that there are 4 cores available, the group of 4 test
cases will run at roughly one fourth of the time for the original
test case.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
