this is probably not an exhaustive set of potential errors, but it
accounts for all the possible ones i've seen as i've been working on
this, that are basically always a result of "bad data".
still a bit worried about potential panics also resulting from bad data
related to overflows and such things ...but have not seen any so far
i don't know how much better or worse either one is really, but i think
i like to_array() better overall. guessing to_array() is probably a bit
better overall, as it should only be one allocation in all cases
this is not actually recommended, as it _technically_ does "mess up"
the sequence (1-3 zero-bytes are being encrypted along with your 1-3
remaining bytes in non-dword-sized data buffers, but those additional
encrypted zero-bytes are not being given back to you at the end).
however, in my opinion, this is quite unlikely to pose a problem for
anyone. for dealing with PSO packets, i'm pretty sure all of those end
up being dword-sized anyway, so no issue there. for encrypting and
decrypting offline quest data, the compressed bin/dat data _could_
technically be non-dword-sized (as i actually encountered today) so you
would otherwise need to pad the input data before calling crypt()
anyway. and in this case you are not going to be using that very same
Crypter instance to do any further encrypting/decrypting ... so it's
actually no problem at all.
so, to me, the convenience of having crypt() just automatically be able
to deal with any arbitrary size of data was worthwhile.
meh.
get rid of the generalized traits that the read/write methods were
located in. now those methods are just located directly in the struct
impl itself
also cleaned up quest bin/dat errors
added validation checks in quest bin/dat reading
since we're doing offset/length checks regardless, calling memcmp here
instead of doing a slice comparison is at least twice as fast during
non-release builds. this is nice, as prs_compress can be quite slow
during non-release builds. and obviously during release builds, this
would be compiled down to a memcmp-equivalent anyway.
use individual error types for both bin and dat modules instead of
all three modules sharing the same error type. maybe marginally better
this way? at least should generally be more clear about whether the
error is related to a bin, dat or general quest processing now
Gered