The default is to execute the script (iscsid_volumes=YES), so if you have
any volumes defined, you should also start iscsid (iscsid=YES) to avoid
error messages.
In symtab_search, most of the conditions were redundant, so remove them.
In read_byte, using CHAR_MASK was conceptually wrong, as that constant
is from the target platform while the lexical analysis happens on the
host platform. It was unnecessary as well, as a hypothetical host
platform with 36-bit chars might encode the characters from the basic
source character set as numbers higher than 0x0_0000_00ff. Since lint
assumes that both the source character set as well as the execution
character set are the same and based on 8-bit bytes, nothing changes.
No functional change.
reduces the size of a non-x11 i386 build by 38% - 992MiB -> 612MiB,
and likely similar reductions elsewhere. it also reduced the build
time by about 3%, perhaps from less IO to write and less data to
compress. for amd64, the size was reduced 1137MiB -> 741MiB, about
35%, though i don't have timing guesses here.
note that these are sizes of .gz not .xz (i enable pigz for my
builds), and this probably has a much greater benefit for xz builds
as the sets creation phase is much slower there.
Adjust previous change so that it only replaces my home-grown define
for the end marker with the new official DDB_END_CMD marker that it
introduced. Undo the rest of that last change.
As the author of this example I'm pretty sure what example I wanted to
set and this narration order is an important part of it.
If the input cannot be split into the number of files resulting from the
default suffix length, automatically extend the suffix length rather than
bailing out with 'too many files'.
Suffixes are extended such that the resulting files continue to sort
lexically and "cat *" would reproduce the input. For example, splitting
a 1M lines file into (default) 1000 lines per file would yield files
named 'xaa', 'xab', ..., 'xyy', 'xyz', 'xzaaa', 'xzaab', ..., 'xzanl'.
If '-a' is specified, the suffix length is not auto-extended.
This behavior matches GNU sort(1) since around version 8.16.
64KB (0x800000 - 0x7f0000) is not enough for the bootloader itself
and more spaces are required for heap on loading a kernel.
https://mail-index.netbsd.org/port-vax/2023/01/24/msg004149.html
"Go ahead" from ragge@. Should be pulled up to netbsd-10 and netbsd-9.