Add defer delete for encoded strings across all test procedures to ensure
proper cleanup and prevent memory leaks. This completes the memory
management improvements started in 591dd876.
Add test case to verify custom alphabet support. The test uses a
decimal-uppercase alphabet (0-9, A-V) to test both encoding and decoding
with custom tables, including validation. This ensures the encode and
decode functions work correctly with custom encoding tables and
validation functions as documented.
Remove premature deallocation of the output buffer which was causing
use-after-free behavior. The returned string needs to take ownership
of this memory, but the defer delete was freeing it before the
string could be used. This fixes issues with encoding that were
introduced by overly aggressive memory cleanup in 93238db2.
Add test_base32_roundtrip() to verify the encode->decode roundtrip
preserves data integrity. This test helps ensure our base32 implementation
correctly handles the full encode->decode cycle without data loss or
corruption.
The decoding table was only 224 bytes which caused type mismatches when
using custom alphabets, so expand with zeroes to cover full byte range
while maintaining the same decoding logic.
Fix encoding to properly use provided encoding table parameter instead of
hardcoded `ENC_TABLE`.
This makes encode properly support custom alphabets as documented.
Add support for custom alphabet validation through an optional validation
function parameter. The default validation follows RFC 4648 base32
alphabet rules (A-Z, 2-7).
This properly supports the documented ability to use custom alphabets.
Replace package-level map with a simple switch statement for padding
validation. This eliminates allocations we can't properly free while
maintaining the same validation logic.
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.
