Closed pnelson closed 3 weeks ago
The old behavior was certainly confusing. I also thing the behavior of pushing the uint16 integers is wrong, too - we should fix that.
That said, I should point out that the FFI module has a much more general implementation of pushing bytes to buffers.
For example,
(ffi/write :uint16 100 @"") # -> @"d\0"
(ffi/read :uint16 @"d\0") # -> 100
Thanks for the quick turnaround! Control over endianness was required for my use case but I didn't see a way to do so with the FFI module.
I was using the newer
buffer/push-uint[16|32|64]
functions and ran up against issues with upper limits.This fixes the issue. I think it is fair that negative numbers here raise bad slot errors so I modified those tests to test the upper bounds instead.
Well,
buffer/push-uint16
anything0xFFFF <= x <= 0xFFFFFFF
will push"\xff\xff"
without error until it exceedsuint32_t
. We could add a similarjanet_getuinteger16
,janet_checkuint16
, andjanet_checkuint16range
if that's an issue. Might look better to rename the 32-bit functions for consistency as well in that case so I thought I'd get feedback first if this is enough or what path we should take.