| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* ffi.c (ffi_type_copy): Function moved earlier in file
without change.
(ffi_type_copy_new_ops): New stati function.
(make_ffi_type_enum): Do not create a new type object using
cobj; copy the existing base_type, and then tweak its
properties, just like what is done with bool. Thus if
base_type is a bitfield, the enum will be a bitfield.
Add check against doign this to anything but an FFI_KIND_NUM,
with the awareness that this does include floating-point types.
Since tft is now a copy, we no longer have to copy a number of
things from btft. We do set he kind field to FFI_KIND_ENUM.
(ffi_type_compile): In the two bitfield cases, we now
calculate the mask field for the bitfield type (leaving the
shift at zero). The struct or union type into which the
bitfield is embedded will still re-calculate this.
The reason is that when an (enumed (bit ...) ...) type is
defined, it constructs hash tables for converting between the
symbolic and numeric values. It calls the put function of the
underlying type to test whether each enumeration value can be
converted (i.e. is in range). So the bitfield type must have a
valid mask at that time, or else it will reject every nonzero
value as being out of range for the bitfield. I'm also
replacing the max_int variable with bits_int. Since bitfields
are restricted to no wider than int, why pretend?
* tests/017/ffi-misc.tl: New test cases.
* txr.1: Documented.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Reported by Paul A. Patience.
* ffi.c (make_ffi_type_enum): Do not use the cnum native type
for doing the member value calculations. Work with Lisp
numbers, and verify their range by passing them into the put
function of the underlying integer type. Duplicated code is
merged, too.
* tests/017/ffi-misc.tl: New tests. Two 64 bit ones fail
due to conversion bugs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* utf8.c (utf8_from_buffer): Fix incorrect backtracking logic
for handling bad UTF-8 bytes. Firstly, we are not backtracking
to the correct byte. Because src is incremented at the top of
the loop, the backtrack pointer must be set to src - 1 to
point to the possibly bad byte. Secondly, when we backtrack,
we are neglecting to rewinding nbytes! Thus after
backtracking, we will not scan the entire input. Let's avoid
using nbytes, and guard the loop based on whether we hit the
end of the buffer; then we don't have any nbytes state to
backtrack.
* tests/017/ffi-misc.tl: New test case converting a three-byte
UTF-8 encoding of U+DC01: an invalid character in the
surrogate range. We test that the buffer decoder turns this
into three characters, exactly like the stream decoder.
Another test case for invalid bytes following a valid
sequence start.
|
|
|
The undimensioned (array <type>) and (zarray <type>) types are
not doing UTF-8 conversion when <type> is char or zchar,
or doing what they are supposed to with the FFI character
types, which is inconsistent from their dimensioned
counterparts.
* ffi.c (ffi_varray_dynsize): if the element type is marked
for character conversion, then do the size calculation for
char and zchar by measuring the UTF-8 coded size.
(ffi_varray_alloc): Call ffi_varray_dynsize to get the size,
to benefit from the char handling. Thus when FFI allocates
buffers for a variable length array, it will allocate correct
size required for the UTF-8 encoded string.
(ffi_varray_put, ffi_varray_in): Here we must call
ffi_varray_dynsize and divide by the element type to get the
proper numer of elements. Then we must check for character
conversion and handle the cases.
(ffi_varray_null_term_in): Check for character conversion
cases and route those through ffi_varray_in, which handles
null-terminated strings.
* tests/017/ffi-misc.tl: New file.
* tests/017/ffi-misc.expected: New file.
|
