Fix PER encoding of empty octet strings missing the length determinant

[decryphe]

During implementation of some more advanced ASN.1 descriptions, we ran across an issue where the length determinant would not be part of the payload if an octet string had an effective zero length.

This wasn't initially an issue, because the string we were parsing was located at the end of the buffer, and with zero initialized memory (on the C-parser-side), it found the correct length determinant of zero by accident. While building round-trip unit-tests for our payloads, this blew up - hence the amount of test code for the single line fix... :-)

I've tried to write some good-case/bad-case tests to not break any other functionality, and kept all other tests that I wrote while investigating the issue.

Happy new year! 🎉

[XAMPPRocky]

Thank you for your PR! The code looks good but it is failing tests.

[decryphe]

I tried running cargo test, cargo test --all-targets, cargo clippy --all-targets. I'm on cargo 1.84.0-beta.5 (66221abde 2024-11-19) - what did I miss?

[XAMPPRocky]

Have tried with --workspace?

[decryphe]

I tried both cargo test and cargo clippy with --all-targets --workspace, anything else I should try?

[XAMPPRocky]

Looking at the failed targets, they seem to be 32 bit, can you try compiling the workspace for one of the failed targets?

[decryphe]

Yep, finding it by running cross test --target i686-unknown-linux-gnu --workspace, it was easy to see that I had done an indexed access into a usize.to_be_bytes() array. Fixed and amended.