Previously, the buffer_index parameter was unused, causing all writes to
use the buffer index of zero, which is not necessarily what is wanted
all the time.
Thankfully, all current usages don't use a buffer index other than zero,
so this just prevents a bug before it has a chance to spring.
We can avoid constructing a std::vector here by simply passing a pointer
to the original data and the size of the copy we wish to perform to the
backend's Write() function instead, avoiding copying the data where it's
otherwise not needed.
We were using a second std::vector as a buffer to convert another
std::vector's data into a byte sequence, however we can just use
pointers to the original data and use them directly with WriteBuffer,
which avoids copying the data at all into a separate std::vector.
We simply cast the pointers to u8* (which is allowed by the standard,
given std::uint8_t is an alias for unsigned char on platforms that we
support).
Previously we were just copying the data whole-sale, even if the length
was less than the total data size. This effectively makes the
actual_data vector useless, which is likely not intended.
Instead, amend this to only copy the given length amount of data.
At the same time, we can avoid zeroing out the data before using it by
passing iterators to the constructor instead of a size.
These are unused and essentially don't provide much benefit either. If
we ever need rotation functions, these can be introduced in a way that
they don't sit in a common_* header and require a bunch of ifdefing to
simply be available
Android and macOS have supported thread_local for quite a while, but
most importantly is that we don't even really need it. Instead of using
a thread-local buffer, we can just return a non-static buffer as a
std::string, avoiding the need for that quality entirely.
Previously is_hfs and pfs_header members wouldn't be initialized in the
constructor, as they were stored in locals instead. This would result in
things like GetName() and PrintDebugInfo() behaving incorrectly.
While we're at it, initialize the members to deterministic values as
well, in case loading ever fails.
Lioncash