Issue #698 points out an bug related to reloading. The illustious
hellerve@ has discovered that the issue relates to types defined in
modules--for some reason, upon reloading, the type's delete, copy, etc.
functions are doubly defined, resulting in too high or a number of
functions for Carp to work out the dependencies.
Instead of returning an array of Maybe UintNs, we now return a pair
comprised of the array of interpreted int values and the number of bytes
that were'nt read/interpreted.
We also provide an `exact` variant of this function that returns a
Result instead of a Pair. If there are excess bytes in the sequence one
attempts to interpret, the `exact` functions return a `Result.Error`
containing the number of extra bytes. If the byte sequence is exact , a
`Success` containing the interpreted values is returned instead.
Specifically, we now reference the explicit unsigned int types we return
in the docs for each function, and I've dropped the term byte-seq in
favor of bytes in all cases.
This change brings the implementation of `byte-seq->int16-seq-unsafe`
into parity with the implementations of its 32 and 64 bit brethren.
I've also cleaned up some of my previous sloppiness:
- Correct function names in doc and sig annotations.
- Remove extra spaces before newlines.
The technique here feels a bit hacky, but it's the common way to do it.
We exploit the fact that ints are 16bits and chars are 8bits to grab the
first byte in a systems int representation, which is indicative of its
endianness.
Since the function is generic over arrays, it makes more sense to house
it here.
I've also fixed an issue with its definition whereby we produced extra
empty arrays when n was greater than the original array length. We now
return an array of a length that matches precisely the number of
partitions with values we're able to create.
The binary module implements functions for interpreting byte sequences
as int16, int32, or int64 values depending on a given endianess (the
Byte module implements support for interpreting bytes as int8 values).
It'd be nice if we could implement these functions in pure Carp, using
the Bytes module--but unfortunately we need to rely on some type
conversions in C, which are only possible by registering C functions for
performing the necessary conversions.
At the moment, all of these functions are unsafe (they access byte
arrays using unsafe-nth).
