After all the previous work, we can now base64 decode nsString types
without intermediate conversion steps to nsCString, which is faster and
more memory-efficient.
The current nsString decoding routine indirectly relies on the various
checks this routine performs; making it generic over string types
ensures that we can eventually call it directly from the nsString
decoding routine.
The existing Base64URL code converts from `const char` to `uint8_t`.
We're going to want versions that convert from character types to
character types, so make the decode routines accept generic input and
output types.
The decoding logic is the same for Base64 and Base64URL; we might as
well reuse the routines that we already have for Base64URL decoding so
we don't make mistakes in the logic.
These tables are nearly identical to the ones for base64url decoding,
but ideally will be slightly more readable, since things are broken up
into sets of eight entries at a time.
After all the previous work, we can base64 encoding nsString values
directly into nsString values, without having to go through intermediate
nsCString values. Since this routine backs base64 routines exposed to
the web, this change should help with OOMs that we see associated with
base64 encoding.
The nsACString -> nsACString encode routine has several checks in it for
correct operation, and the nsAString -> nsAString encode routine relies
on those checks happening via the nsACString -> nsACString routine.
Once we start encoding nsAStrings directly, we'll still need those
checks, and the easiest way to ensure they happen is to move the core
base64 encode logic for strings into a templated helper.
One less use of NSPR is a good thing. The failure cases that
PL_Base64Encode would have caught for us are:
1. "Truncation".
2. Integer overflow when computing destination string length.
3. Malloc failures.
The first one only gets checked if we pass in zero for the source
length, which we never do. The latter two only get checked if we pass
in a null pointer for the destination, which we never do. So removing
the error handling PL_Base64Encode implies here is a good thing.
The lossy conversion to ASCII here can also fail; we should handle that
as well. Rewriting the code to use MakeScopeExit also avoids tangled
logic and/or duplicating calls to ensure the destination string is
truncated on failure.
Slightly less than half (93 / 210) of the NS_METHOD instances in the codebase
are because of the use of NS_CALLBACK in
nsI{Input,Output,UnicharInput},Stream.idl. The use of __stdcall on Win32 isn't
important for these callbacks because they are only used as arguments to
[noscript] methods.
This patch converts them to vanilla |nsresult| functions. It increases the size
of xul.dll by about ~600 bytes, which is about 0.001%.
--HG--
extra : rebase_source : c15d85298e0975fd030cd8f8f8e54501f453959b
This will be used in bug 1273711 to avoid an OOM.
This also tweaks one of the existing overloadings of Base64Encode to return
NS_ERROR_OUT_OF_MEMORY on OOM instead of NS_ERROR_INVALID_ARG.
--HG--
extra : rebase_source : a2ad472b11ac2c858487bf5fdae84d183084773b
The argument naming in Base64.{h,cpp} is horribly confused, with a lot of them
gotten backwards. This patch fixes that, and also introduces a more consistent
naming scheme for arguments and local variables: "binary" is used for binary
data, and "base64" is used for base64-encoded data.
This patch doesn't change any functionality.
--HG--
extra : rebase_source : 7d8a08762e291851bd117a0409fc8715b830fdbe
The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
