Fix memory handling throughout base32 package:
- Make padding map package-level constant (to avoid repeated allocs)
- Use passed allocator in encode's make() call
- Add defer delete for allocated memory in encode
- Add proper cleanup in test cases
- Fix memory cleanup of output buffers
The changes ensure consistent allocator usage and cleanup in both
implementation and tests.
Add test suite based on RFC 4648 test vectors and validation rules:
- Add section 10 test vectors for valid encoding/decoding
- Add test cases for invalid character handling (section 3.2)
- Add test cases for padding validation (section 4)
- Add test cases for length requirements (section 6)
The test vectors verify that:
- Empty string encodes/decodes correctly
- Standard cases like "foo" -> "MZXW6===" work
- Invalid characters are rejected
- Missing or malformed padding is detected
- Invalid lengths are caught
Fix buffer allocation size calculation and add proper bounds checking to
ensure output buffer has sufficient space. This fixes crashes that could
occur with inputs like "AA" and other edge cases where the output buffer
was too small.
Remove #no_bounds_check as proper bounds checking is necessary for safe
error handling. The small performance trade-off is worth the improved
robustness.
Replace assertions with proper error handling in base32.decode() to allow
programs to handle invalid input gracefully rather than crashing.
The function now returns ([]byte, Error) instead of just []byte.
If a procedure was marked `#force_no_inline`, any procedure calls within
it would also implicitly be. This is not expected for multiple reasons:
1. `#force(_no)_inline` on a call expr works differently than on a procedure literal.
2. Adding the attribute on it and every called proc blows up the amount
of work for the inliner pass and may increase the time it takes.
3. Putting `#force_no_inline` on a procedure to keep executable size
down (like we do for some map procedures), benchmark it, or find it in
asm/ir has the added effect of slowing those procedures down significantly
and not representing truth.
This test is definitely imperfect (should have no erroneous failures,
only erroneous passes), but should serve as a good smoke test
if matrix alignment is ever broken again. Looking at the generated LLVM,
there is a bunch of weird choices for alignment chosen that might be
worth looking into.
It's also worth noting that the failure mode of this test is a #GP
exception, which I don't know how well the test runner handles in a
larger test corpus.
Zoltán Kéri
Jeroen van Rijn
gingerBill
imlodinu
Courtney Strachan
Gabriel Pariat
Laytan
Giuliano Macedo
gingerBill
GonkieDev
shashank
wrapperup
Gavin
dozn
Tina Colvin
Adam Zadrożny