Test both types of empty data lines (empty text line and empty request line)
in both layout contexts (data layout line and horizontal line layout line),
making sure that tbl_data.c rev. 1.48 handles all code paths in tbl_data()
correctly.
When a text line in tbl(7) data is completely empty (""),
do not access the byte beyond the terminating NUL byte.
Instead, generate an empty span that contains no data cells,
optionally preceded by a horizontal line if requested by the layout.
This buffer overrun reading exactly one byte too far usually had
no adverse consequences. No matter the value of the wrongfully read
byte, the code would correctly continue after the "if" block,
either (more likely) via failing the p[1] == '\0' condition
or (less likely) via the default branch of the switch.
Theoretically, it might segfault on the one-byte access, though.
Patch from Hippolyte d'Oncieu de la Batie <hippolyte.doncieu at gmail.com>
who found this bug using clang-14 with libFuzzer and AddressSanitizer.
Reported via espie@.
Clarifying source code comment by me.
Update to emacs-31.1
https://www.gnu.org/software/emacs/news/NEWS.31.1
The most prominent change is probably the warnings spewed about
lexical-binding. To safely get rid of them you may add a cookie to your
.el files that explicitely disables lexical binding (dynamic binding has
been the default for years). You may also enable lexical binding which
allegedly has advantages (more efficient, less error prone) after
auditing your elisp code.
Tested by kirill@ namn@ izzy Meyer gkoehler@ matthieu@
ok kirill@ matthieu@
pf(4) is still overly strict in filtering MLD messages
pf(4) may drop valid Multicast Level Discovery (MLD) packet
with unspecified source address. According to RFC 3590,
section 4, Source Selection Guidelines, MLD Report and
MLD Done messages may be carried by IPv6 datagrams with
unspecified source address.
Issue reported and patch kindly submitted
by Kristof Provost (kp _at_ FreeBSD _dot_ org)
OK bluhm@
pax: Ensure when removing ".." path components extra slashes are also
removed.
A specially constructed archive could trick pax into extracting outside
of the working directory. This also fixes a string ending in a compoment
of exactly ".." reading one past the NUL.
ok millert@
