install: Bump compare size limit (128MB) to support large binaries
Preserve metadata and prevent redundant disk writes during builds with
the install's -C (compare) flag.
The previous historical comparison limit of 16MB is insufficient for
modern toolchains, frequently choked or bypassed by a large base
components like LLVM/Clang, kernels, Rust apps, and large runtime
libraries.
By leaving matching files alone, install keeps their modification timestamps
intact. make(1) safely ignores those files on subsequent runs.
Base examples: 15.0 amd64 GENERIC kernel - 28MB, clang - 105MB, lldb - 97MB, etc.
Reviewed by: glebius
Approved by: glebius (mentor)
Obtained from: Fudo Security
MFC after: 2 weeks
[2 lines not shown]
net/sdl3_net: add port: Simple, cross-platform wrapper over TCP/IP sockets
This is a portable network library for use with SDL. It's goal is
to simplify the use of the usual socket interfaces and use SDL to
handle common portable functionality such as threading and reporting
errors.
syslogd: Fix ereregex property filters and add test
This change fixes Bug 293879, where ereregex filters in syslogd
did not handle alternation correctly.
The issue appears to come from mixing up two different kinds of
flags: syslogd's internal serialized filter flags in
usr.sbin/syslogd/syslogd.h, and the regex compilation flags from
include/regex.h. ereregex was storing REG_EXTENDED in cmp_flags,
even though cmp_flags is meant to carry syslogd's own FILT_FLAG_*
values for configuration serialization and reconstruction.
REG_EXTENDED has the same bit value as FILT_FLAG_EXCLUDE, so the
filter could be reconstructed with the wrong semantics.
The fix stores FILT_FLAG_EXTENDED instead, allowing syslogd to
correctly REG_EXTENDED when compiling the regex.
A test was also added for both ereregex and !ereregex filters.
[8 lines not shown]
netmap: silence -Wdefault-const-init-field-unsafe warning
The netmap_ring struct starts with various const members and rencent
clang warns about leaving them uninitialized. Having them const in the
first place is highly suspicious since they are updated with various
macros but using hand-coded __DECONST(). But fixing that is a more
invasive change that I am unable to test.
```
.../freebsd/sys/dev/netmap/netmap_kloop.c:320:21: error: default initialization of an object of type 'struct netmap_ring' with const member leaves the object uninitialized [-Werror,-Wdefault-const-init-field-unsafe]
320 | struct netmap_ring shadow_ring; /* shadow copy of the netmap_ring */
| ^
.../freebsd/sys/net/netmap.h:290:16: note: member 'buf_ofs' declared 'const' here
290 | const int64_t buf_ofs;
| ^
```
Test Plan: Compiles
[5 lines not shown]
if_ovpn.c: fix use of uninitialized variable
In case we use OVPN_CIPHER_ALG_NONE, the memcpy will attempt to copy 0
bytes from an uninitialized pointer. While the memcpy() implementation
will treat this as a no-op and not actually dereferece the undefined
variable it is still undefined behaviour to the compiler and should be
fixed. Found by building with clang HEAD
Reviewed by: kp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D52543
(cherry picked from commit 969be39fb3caf4272f128dbf3267ceba5966a6ce)
netmap: silence -Wdefault-const-init-field-unsafe warning
The netmap_ring struct starts with various const members and rencent
clang warns about leaving them uninitialized. Having them const in the
first place is highly suspicious since they are updated with various
macros but using hand-coded __DECONST(). But fixing that is a more
invasive change that I am unable to test.
```
.../freebsd/sys/dev/netmap/netmap_kloop.c:320:21: error: default initialization of an object of type 'struct netmap_ring' with const member leaves the object uninitialized [-Werror,-Wdefault-const-init-field-unsafe]
320 | struct netmap_ring shadow_ring; /* shadow copy of the netmap_ring */
| ^
.../freebsd/sys/net/netmap.h:290:16: note: member 'buf_ofs' declared 'const' here
290 | const int64_t buf_ofs;
| ^
```
Test Plan: Compiles
[5 lines not shown]
if_ovpn.c: fix use of uninitialized variable
In case we use OVPN_CIPHER_ALG_NONE, the memcpy will attempt to copy 0
bytes from an uninitialized pointer. While the memcpy() implementation
will treat this as a no-op and not actually dereferece the undefined
variable it is still undefined behaviour to the compiler and should be
fixed. Found by building with clang HEAD
Reviewed by: kp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D52543
(cherry picked from commit 969be39fb3caf4272f128dbf3267ceba5966a6ce)
ucode: Fix validation on Intel platforms
The check for the extended signature table was backwards, so we always
ignored it.
We should verify that the extended signature table fits within the total
image size.
Reviewed by: jrm, kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D57209
