summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* I/O convenience functions get mode-opt argument.Kaz Kylheku2022-05-272-56/+136
| | | | | | | | | | | | | | | | | | | | | This is motivated by the desired to be able to specify gzip compression: e.g. (file-put-string "file.gz" "abc" "z") However, it has other uses. For instance with "x", we can exclusively create a file with content in one call. * stdlib/getput.tl (file-get, file-put, file-append, file-get-string, file-put-string, file-append-string, file-put-lines, file-append-lines, file-get-buf, file-put-buf, file-place-buf, file-append-buf, file-get-json, file-put-json, file-append-json, file-get-jsons, file-put-jsons, file-append-jsons): New option argument which combines with the open-file mode. * txr.1: Documented.
* open-fileno: support "z" flag for gzip.Kaz Kylheku2022-05-261-12/+27
| | | | | * stream.c (open_fileno): Use w_gzdopen_mode and make_gzio_stream to make a gzio stream if the gzip flag is present.
* gzio: support more modes in open-file.Kaz Kylheku2022-05-264-3/+49
| | | | | | | | | | | | * gzio.c (w_gzopen_mode): Use w_open_mode if available, in order to support most of the flags (including "x" which Zlib has, but which we are not passing through). * stream.c (w_open_mode): New function formed from w_fopen_mode content. (w_fopen_mode): Call w_open_mode. * stream.c (w_open_mode): Declared.
* First cut at new feature: gzip streams.Kaz Kylheku2022-05-266-9/+631
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Makefile (OBJS): Conditionally include new gzio.o object file. * configure: Detect external zlib, setting up new have_zlib variable in config.make, HAVE_ZLIB in config.h, and also -lz in conf_ldlibs. * gzio.[ch]: New files, implementing the stream abstraction over the gzip file I/O routines in zlib. * stream.h (struct stdio_mode): New gzip flag and gzlevel bitfield to hold a value 0 to 9. (stdio_mode_init_blank, stdio_mode_init_r, stdio_mode_init_rpb): Update intializers to cover new bitfield members. * stream.c: Include <zlib.h> and "gzio.h" if HAVE_ZLIB. (do_parse_mode): Recognize new mode modifier letter "z", setting the gzip flag in the mode structure. If it's followed by a digit, set the gziplevel to that value. (format_mode): Don't output "b" letter for binary mode if gzip is set, because gzopen interprets "b" differently. Don't put out "t" if gzip is set. If gzip mode is specified, do put out the level. If gzip is set, and gziplevel is nonzero then encode the level: gzopen will understand it. (open_file): If gzip mode is requested, then open the file using gzopen mode, a new function in gzio.c. The return a gzio stream based on the returned gzip file handle. However, if we are reading, and the gzip stream indicates that it's not decompressing anything, then we close it and open the file using an ordinary stream. (stream_init): Call gzio_init if HAVE_ZLIB is true. This is done here because the module is integrated with stream.c, and also so that lib.c doesn't have to know about HAVE_ZLIB and <zlib.h>.
* open-file: show function name in bad modes diagnostic.Kaz Kylheku2022-05-261-1/+2
| | | | | | * stream.c (normalize_mode): Include the self symbol in the error message being thrown. This was not forgotten in the sister function normalize_mode_no_bin.
* stream-set-prop: return t on successful :name set.Kaz Kylheku2022-05-261-0/+1
| | | | | | * stream.c (stdio_set_prop): When setting the :name property, return t, to indicate it was recognized and stored, as is documented.
* streams: avoid double access to errno.Kaz Kylheku2022-05-261-2/+3
| | | | | * stream.c (stdio_maybe_read_error): Access errno once, and refer to the value.
* configure: don't exit on no mmap.Kaz Kylheku2022-05-261-2/+0
| | | | | | * configure: do not treat the failure to detect mmap as a fatal condition. This was just debugging commands accidentally left behind.
* tests: fix failing load-search test.Kaz Kylheku2022-05-261-1/+2
| | | | | | * tests/019/load-search.tl: skip a certain test if it is run as superuser; it fails because superuser is not affected by denied directory search and execute permissions.
* Version 276.txr-276Kaz Kylheku2022-05-247-699/+787
| | | | | | | | | | | | | | * RELNOTES: Updated. * configure (txr_ver): Bumped version. * stdlib/ver.tl (lib-version): Bumped. * txr.1: Bumped version and date. * txr.vim, tl.vim: Regenerated. * protsym.c: Likewise.
* ffi: reproduce odd GNU C behavior for aligned bitfields.Kaz Kylheku2022-05-243-7/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | We've already taken care of imitating the situation that GNU C allows __attribute__((aligned(n))) to weaken the alignment of a bitfield, contrary to it being documented that align only strengthens alignment. Even a value of n == 1 is meaningful in that it can cause the bitfield to start allocating from a new byte. This patch corrects a newly discovered nuance: when a bitfield is attributed with a weaker alignment than its underlying type (e.g. uint32_t field marked with 2 byte alignment), the original type's alignment is still in effect for calculating the alignment of the structure, and the padding. * ffi.c (struct txr_ffi_type): New member oalign, for keeping track of the type's original alignment, prior to adjustment. (make_ffi_type_struct): For a named bitfield, take the oalign value into account when determining the most strict member alignment. (ffi_type_compile): When marking a type as aligned, the we remember the original alignment in atft->oalign. * tests/017/bitfields.tl: New test case, struct s16. * txr.1: Documented.
* fixup! ffi: couple of tests; assertion.Kaz Kylheku2022-05-241-5/+5
|
* doc: add a note about pack.Kaz Kylheku2022-05-241-0/+34
| | | | | * txr.1: pack with alignment values greater than 1 doesn't directly correspond to a single GNU C feature.
* ffi: couple of tests; assertion.Kaz Kylheku2022-05-242-0/+15
| | | | | | | | | | | | | * ffi.c (make_ffi_type_struct): Add check for impossible condition. The bits_alloc variable could only exceed bits_type (and thus cause the room variable to have a nonsensical, large value) if the bitfield allocation tried to continue allocating bits into an aligned unit, whose alignment exceeds the size of the underlying type. But in that case, tft->aligned would have to be true, and so the offset would have been aligned prior to this code, rendering bits_alloc zero. * tests/017/bitfields.tl: New tests.
* oop: corruption bugfix.Kaz Kylheku2022-05-231-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | * struct.c (alloc_seen): Fix under-sized alloca and memset, where the size being used is the number of elements, but should be the number of bytes. This showed up as a failure in the tests/012/oop-mi.tl on PPC64, uncovered by a completely unrelated change in eval.c. The unrelated code never executes during the failed test case; it just affects some memory contents of the stack somehow. The under-allocated array is used during structure type initialization to hold a bitmask which helps to suppress the duplicate initiation of base structures which are inherited multiple times (duplicate bases). I think why this shows up on PPC64 is the big endian order. The sizes involved are small. The test case has a couple of duplicate bases only, but a full 64 bit mask needs to be allocated for that since the mask is an array of ucnum. On little endian, it doesn't matter than only a single byte is allocated: that is enough for 8 duplicate bases, and because of the byte order, those bases land into the byte that is allocated. On big endian, the bases will be on the high part of the 64 bit word, and thus over in the area we didn't allocate. To reproduce an issue on little endian, you need an inheritance hierarchy with more duplicate bases.
* ffi: bitfield tests pass on PPC64.Kaz Kylheku2022-05-231-102/+53
| | | | | | * ffi.c (swap_get32, swap_put32, swap_get64, swap_put64): correct implementations for operating on little-endian words on big endian.
* ffi: bitfield tests and fixes.Kaz Kylheku2022-05-233-17/+615
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bitfield allocation rules are wrong. Some of it is due to the recent changes which are based on incorrect analysis, but reverting things doesn't fix it. The idea that we compare the current member's alignment with the previous is wrong; it is not borne out by empirical tests with gcc. So we do a straight revert of that. In GNU C, an __attribute__((aligned (N))) attribute applied to a bitfield member will perform the requested alignment if, evidently, the bit field is already being placed into a new byte. (If the bit field is about to be packed into an existing byte, then there is a warning about the align attribute being ignored). Because we don't have alignment as a member attribute, but only as a type attribute, we must implement a flag which indicates that a type has had align applied to it (even if the alignment didn't change) so we can then honor this in the right place in the bitfield allocation code. * ffi.c (struct txr_ffi_type): New attribute flag, aligned. (make_ffi_type_struct): Remove the prev_align variable and all related logic. Consolidate all alignment into one place, which is done before we allocate the bitfield or regular member. We align if the new member isn't a bitfield, or even if it is a bitfield if it has the aligned attribute, or if the bitfield is changing endian compared to the previous member (our local rule, not from GNU C). (ffi_type_compile): The align and pack operators now set the aligned attribute, except in the (pack 1 ...) case which semantically denotes lack of alignment. * tests/017/bitfields.tl: New file. * txr.1: Documented.
* ffi: allow bitfields based on endian types.Kaz Kylheku2022-05-222-210/+598
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is very nice: you can now declaratively match a structure that uses bitfields, and comes from a different endian system. * ffi.c (ffi_kind_t): Replace FFI_KIND_NUM type with FFI_KIND_INT, FFI_KIND_UINT and FFI_KIND_FLO. Now using the tft->kind value, we can distinguish integer and floating types, and determine signedness. (struct txr_ffi_type): New flag, bigendian, which is set to 1 for all big types that are big endian. This is not just the endian types like be-int32, but natural types like int, if the underlying platform is big endian. (swap_get32, swap_put32, swap_get64, swap_put64): New static functions. (ffi_generic_swap_fat_ubit_put, ffi_generic_swap_fat_sbit_put, ffi_generic_swap_fat_ubit_get, ffi_generic_swap_fat_sbit_get, ffi_generic_swap_ubit_put, ffi_generic_swap_sbit_put, ffi_generic_swap_ubit_get, ffi_generic_swap_sbit_get): New static functions. (ffi_make_type_builtin): On big endian, set the bigendian flag on every type. For the endian types, this will get adjusted as an additional construction step. (make_ffi_type_endian): New static function. Calls ffi_make_type_builtin, and then initializes the bigendian flag with the given value. (make_ffi_type_struct, make_ffi_type_union): Because bitfields can have endiannness now, we can no longer refer to the machine's own endianness in laying them out; we have to look at the mtft->bigendian value. Furthermore, we need an additional rule: when a bitfield member follows a member that has different endian, a new allocation unit has to begin. (ffi_type_compile): the sbit and ubit types must set the type to FFI_KIND_INT and FFI_KIND_UINT now. For the big operator, we can simplify the error checking: instead of exhaustively comparing the type to all the supported integer types, we just now check whether it is FFI_KIND_INT or FFI_KIND_UINT. Here, if we detect that an endian bitfield has opposite byte order from the machine, then we instantiate the bitfield with the ffi_generic_swap_* virtual functions. These perform the required byte swapping accesses to the bitfield storage cells, so then the bit field manipulation code just works using the local integer representation (shifting and masking). Of course, the shift amount depends on the endian; and that is calculated at type creation time in make_ffi_type_struct. (ffi_init_types): Replace FFI_KIND_NUM with the appropriate constant for each affected type. In some cases, we have to calculate whether to use the INT or UINT one, for the types whose signedness is not specified. We switch all the endian types to new constructor make_ffi_type_endian, passing the required value of the bigendian flag. * txr.1: Documented.
* ffi: fat bitfield bugfix for big endian.Kaz Kylheku2022-05-211-2/+12
| | | | | | | * ffi.c (make_ffi_type_struct, make_ffi_type_union): We must take fat bitfields into account when calculating mtft->shift on big endian. We must subtract from bits_llint not bits_int for big endian.
* ffi: floating-point endian types: wrong Lisp type.Kaz Kylheku2022-05-211-4/+4
| | | | | | | | | * ffi.c (ffi_init_types): The be-float, be-double, le-float and le-double types wrongly have integer indicated as their Lisp type symbol; it should be float. This doesn't fix any actual bug; the Lisp type is only important for structures/unions. The conversion of be-double is driven by the behavior of the type's virtual functions, which don't look at the Lisp type symbol.
* tests: add forgotten test for new expansion rule.Kaz Kylheku2022-05-211-0/+11
| | | | | | | | This was developed together with what became the May 12 commit 1162a735b61c1c5086fb6055471ee35cc8ed62a4; I just forgot to git add the file. * tests/011/macros-4.tl
* ffi: flex structs: minor refactor.Kaz Kylheku2022-05-212-4/+12
| | | | | | | | | | | | * ffi.c (ffi_flex_struct_in): Function renamed to ffi_flex_array_len, because its responsibility is determining the length of a flexible array that is not null terminated. We don't pass in the structure's type's descriptor any more, but the member descriptor. (ffi_struct_in, ffi_struct_get): Follow rename and changed parameter conventions. * tests/017/flexstruct.tl: Added test case with nested flexible structure.
* ffi: testing and fixing flexible arrays.Kaz Kylheku2022-05-202-10/+97
| | | | | | | | | | | | | | | * ffi.c (ffi_flex_struct_in): Check for the last member being an array, and not null-terminated. We now check the character conversion disposition of the array. If it has character conversion, then we store the length right into the slot that will become the string. In the no-conversion case, we assume that if the member exists, it's a vector we can resize. Otherwise we plant a vector of the required size. (ffi_varray_put): Only call ffi_varray_dynsize if the Lisp object is a vector. If the Lisp objecct is a number, then use that as the size. Otherwise the size is zero. * tests/017/flexstruct.tl: New file.
* utf8: bugfix: trailing char fragment ignored.Kaz Kylheku2022-05-202-0/+16
| | | | | | | | | | | | | | | | | | | | After "years of trouble-free operation" a bug in the UTF-8 decoder was found, which violates its property that any sequence of bytes will decode to some kind of string, which will encode to the original bytes. When the UTF-8 data prematurely ends in the middle of a valid character, the decoder just drops that data as if it didn't exist. So for instance the two-byte sequence E6 BC should decode to "\xDCE6\xDCBC", since it is a fragment of a three-byte UTF-8 sequence. It actually decodes to the empty string. * utf8.c (utf8_bfom_buffer): When the buffer is exhausted, if we are not in the utf8_init state, it means we were in the middle of a UTF-8 sequence. Walk the bytes from the backtrack point to the end of the buffer and store them into the string as U+DCxx codes. * tests/012/buf.tl: Tests added for this via buf-str, str-buf.
* ffi: pack bugfix and tests.Kaz Kylheku2022-05-203-12/+149
| | | | | | | | | | | | | | * ffi.c (ffi_transform_pack): Fix: return the original syntax in the situation when no cases are recognized, rather than the cdr of the syntax. When the struct/union syntax has no members, return the original syntax to indicate no transformation took place. * txr.1: Document the feature that pack on a typedef name or struct name with no members will do the alignment adjustment only, without the syntactic transformation. * tests/017/pack-align.tl: New file.
* eval: remove message about --backtrace option.Kaz Kylheku2022-05-201-4/+0
| | | | | | | * eval.c (error_trace): Don't mention that --backtrace can be used to enable backtraces. This is not only a nuisance, but appears in packaged programs which do not support such an option, making it highly misleading.
* doc: quasiliteral match: formatting problem.Kaz Kylheku2022-05-201-1/+1
| | | | | * txr.1: fix broken quoting which results in stray " character appearing in rendered output.
* doc: undimensioned arrays may be flexible array members.Kaz Kylheku2022-05-201-4/+9
| | | | | | | * txr.1: The documentation for array and zarray wrongly states that if the dimension is omitted, the type may not be used as a structure member. In fact, it may be used as the last member of a flexible structure.
* doc: grammarKaz Kylheku2022-05-201-2/+2
| | | | * txr.1: two instances of "an incomplete arrays" in FFI doc.
* ffi: behavior of align subject to compat.Kaz Kylheku2022-05-202-1/+18
| | | | | | | * ffi.c (ffi_type_compile): Allow align to weaken (lower) alignment if compatibility 275 or lower is requested. * txr.1: Compat note added.
* ffi: pack: implement documented align transformation.Kaz Kylheku2022-05-201-19/+32
| | | | | | | | | | | * ffi.c (ffi_pack_members): Static function removed. (ffi_transform_pack): New static function. (ffi_type_compile): Rely on ffi_transform_pack to recognize and perform all necessary transformations. Cosmetic issue: when a struct is compiled, and the individual member types undergo transformation during member compilation, the syntax for the struct is nevertheless the original one with the untransformed members.
* New function: trim-path-sepsKaz Kylheku2022-05-205-0/+111
| | | | | | | | | | | | | * stream.c (trim_path_seps): New function. (stream_init): trim-path-seps intrinsic registered. * stream.c (trim_path_seps): Declared. * tests/018/path.tl: New tests. * txr.1: Documented. * stdlib/doc-syms.tl: Updated.
* ffi: bugfix: clone of type points to old self.Kaz Kylheku2022-05-201-2/+6
| | | | | | | | | | | | * ffi.c (ffi_type_copy, ffi_type_copy_new_ops): The cloned txr_ffi_type structure must have a self member which points to the new cobj, not the original one. Otherwise things are inconsistent. For instance if the clone is being made for the purposes of adjusting alignment, any operation which chases the self pointer will be accessing incorrect attributes. One example of this is (alignof foo.bar) where if bar is the clone of a type, this will incorrectly report the alignment of the original from which bar was cloned, and the original alignment, not the adjusted alignment is reported.
* ffi: new pack type operator; align increases only.Kaz Kylheku2022-05-203-38/+237
| | | | | | | | | | | | | | | | | * ffi.c (pack_s): New symbol variable. (ffi_type_compile): Handle new pack type operator together with align. Allow a one-argument form of align and pack in which the value is defaulted. The behavior of align changes: align can only increase alignment now, never decrease, so for instance (align 1 ...) does nothing. pack must be used to decrease alignment. Furthermore, for certain argument types, pack performs transformations of the type syntax, rather than compiling the argument type and producing a variant of it with altered alignment. * txr.1: Documented. * stdlib/doc-syms.tl: Updated.
* ffi: bugfix: transition between bitfield cell sizes.Kaz Kylheku2022-05-191-0/+10
| | | | | | | | | * ffi.c (make_ffi_type_struct): When a bitfield is declared for a type whose alignment is different from that of the previous member, then we start the new bitfield on a fresh alignment. As usual, if the previous member is a bitfield which left a partially filled byte, we skip to the next byte and then do the alignment. This seems to match GCC behavior.
* ffi: bitfield handling when storage cells are packed.Kaz Kylheku2022-05-191-11/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In gcc, bitfields can be declared with overridden alignment; for instance when the entire structure is packed. We must modify the algorithm to make this work. Firstly, we must must pretend that we are filling from the start of the containing alignment unit, not size based unit. For instance, if the cell is an 8 byte type, but the alignment is 1, then we are just filling the current byte, not the current 8 byte multiple. However, the number of bits left (room) is still calculated from the size: so if the byte has been filled with 3 bits, we have 4 left in that byte, and then 7 more bytes, and so 61 bits. Secondly, the case of the zero-bit field is special: it does perform an alignment calculation in terms of multiples of the size, ignoring the declared alignment of the field. Thirdly, when the bits do not fit into the existing room, the offset does not move by the size of the bitfield, but by the alignment unit. For instance, if we have 63 bits left in an 8 byte field that has alignment 1, and we want to place 64 bits into another 8 byte field, then we will just move to the next byte, not to the next 64 bit cell. Starting at the next byte, we pretend we have a fres 64 bit cell, albeit misaligned. * ffi.c (make_ffi_type_struct): Make the above adjustments to the algorithm. Some common values size, alignment, mask) are declared in a wider scope and adjustments made.
* ffi: bugfix: empty structs/unions have alignment of 1.Kaz Kylheku2022-05-192-2/+6
| | | | | | | | * ffi.c (make_ffi_type_struct, make_ffi_type_union): Initialize most_align local variable to 1, so the lower bound of alignment is that, rather than zero. * tests/017/ffi-misc.tl: Tests added.
* ffi: bugfix in fat bitfields.Kaz Kylheku2022-05-191-2/+2
| | | | | | | * ffi.c (make_ffi_type_struct, make_ffi_type_union): Do not fall back from the fat (64 bit) bitfield case to the regular (32 bit) case when the number of bits is less than 32. This is completely wrong.
* ffi: diagnose bitfields wider than type.Kaz Kylheku2022-05-191-6/+6
| | | | | | | | | * ffi.c (ffi_type_compile): Show the original bitfield syntax in the invalid size diagnostics. In the case of the (bit n type) syntax, restrict the maximum bits to the width of the type, not just to 32 or 64. I realize the 8 * tft->size calculation can overflow for huge array types, but it makes no sense to use them as bitfields.
* ffi: support 64 bit bitfields.Kaz Kylheku2022-05-192-22/+222
| | | | | | | | | | | | | | | | | | | | | | | | | * ffi.c (struct txr_ffi_type): Replace unsigned mask member with a union m which holds unsigned mask and 64-bit fmask (fat mask). (ffi_sbit_put, ffi_sbit_get, ffi_ubit_put, ffi_ubit_get): Refer to m.mask. (ffi_fat_sbit_put, ffi_fat_sbit_get, ffi_fat_ubit_put, ffi_fat_ubit_get): New static functions. (ffi_generic_fat_sbit_put, ffi_generic_fat_sbit_get, ffi_generic_fat_ubit_put, ffi_generic_fat_ubit_get): Likewise. (make_ffi_type_struct, make_ffi_type_union): Set up fat mask for bitfields that are wider than int. (ffi_type_compile): Refer to m.mask for the int and unsigned int based bitfields declared with sbit and ubit that don't mention a type. The bit operator now allows int64 and uint64 to be valid types for a bitfield. In this case, the "fat" get and put functions are selected which use 64 bit operations. Thus there is no efficiency impact on non-fat bitfields which continue to use code with 32 bit operands. (ffi_offsetof): Use the bitfield flag in the member's type structure to detect bitfields, rather than the mask.
* ffi: use longlong_t.Kaz Kylheku2022-05-191-4/+8
| | | | | | ffi.c (ffi_init_extra_types): Use longlong_t and ulonglong_t, subject to HAVE_LONGLONG_T. If there is no intmax_t and no longlong_t, don't define intmax-t and uintmax-t.
* ffi: eliminate trivial allocas in bitfield code.Kaz Kylheku2022-05-181-14/+14
| | | | | | * ffi.c (ffi_generic_sbit_put, ffi_generic_sbit_get, ffi_generic_ubit_put, ffi_generic_ubit_get): Replace int-sized alloca with declared int object.
* ffi: alignment bug in undimensioned arrays.Kaz Kylheku2022-05-182-8/+10
| | | | | | | | | | | | | | | | | | | | | | Because the varray behavior for undimensioned arrays was introduced in dubious commit 7880c9b565ab438e1bf0250a967acdbf8d04cb42 in 2017, which used make_ffi_type_pointer to register the type, claiming that the C representation is pointer (which was not true in that commit, nor ever since). As a result, though, undimensioned arrays received the alignment of pointers, rather than deriving it from the element type. Thus (array char) has 4 or 8 byte alignment whereas (array 4 char) correctly has 1 byte alignment. * ffi.c (ffi_type_compile): Use make_ffi_type_array for the two-element array syntax, just like for the dimensioned case with three elements. Then override some of the functions with the varray versions. * tests/017/ffi-misc.tl: Fix the test case which exposed this. In the type (struct flex (a char) (b (zarray char)), the array b must be at offset 1. I didn't notice that the offset of 4 being confirmed by the test case was wrong, but this showed up when running the test case on a platform with 8 byte pointers.
* ffi: fix broken test.Kaz Kylheku2022-05-181-2/+2
| | | | | | | * tests/017/ffi-misc.tl: Fix incorrect test whose loop body does not execute. A remaining issue here is why the diagnostics about unbound functions and variables in the loop body get swept under the rug.
* copy-path-rec: bug: trailing slash fail.Kaz Kylheku2022-05-171-4/+1
| | | | | | | | | * stdlib/copy-file.tl (copy-path-rec): When from-path has a trailing slash, the starts-with test fails, and the operation fails without doing anything. Let's just get rid of that test. It's probably only there because of the ad-hoc path munging that is calculating rel-path. Why don't we just use the rel-path function for that.
* split-str: new count parameter.Kaz Kylheku2022-05-175-13/+103
| | | | | | | | | | | | | | | | | | * eval.c (eval_init): Fix up registration of split-str to account for new parameter. * lib.c (split_str_keep): Implement new optional count argument. (spl): Pass nil value to split_str_keep for new argument. I'd like this function to benefit from this argument also, but the design isn't settled. (split_str): Pass nil argument to split_str_keep. * lib.h (split_str_keep): Declaration updated. * tests/015/split.tl: New tests. * txr.1: Documented.
* doc: grammar under pattern matching.Kaz Kylheku2022-05-171-1/+1
| | | | * txr.1: agreement between "body" and "consist".
* ffi: bugfix: null terminated string as flexible member.Kaz Kylheku2022-05-172-38/+34
| | | | | | | | | | | | * ffi.c (ffi_char_array_get, ffi_zchar_array_get, ffi_wchar_array_get, ffi_bchar_array_get): Rearrange so that we test for tft->null_term first, and not nelem == 0. If nelem happens to be zero, but we are supposed to decode a null-terminated string, we will do the wrong thing and return the null string. (ffi_varray_in): The body can't be conditional on vec being non-nil, because then we do nothing if we don't have a Lisp object, which means we skip the cases when we should decode a null-terminated array. Now if vec is nil, we must guard against calling ffi_varray_dynsize.
* ffi: bugfix: unions are not unconditionally incomplete.Kaz Kylheku2022-05-171-1/+1
|
* New options: --in-package and --compile.Kaz Kylheku2022-05-123-3/+98
| | | | | | | | | * txr.c (help): Mention new options. (do_compile_opt, do_in_package_opt): New static functions. (txr_main): Implement options. * Makefile (COMPILE_TL): Use the options instead of -e. * txr.1: Document.