contrib/flex: Guard against int overflow in sko_push().
sko_sz is an int; doubling it unchecked could overflow and produce a
huge size_t for realloc(). Bail out if it would overflow.
It's sad that the upstream project hasn't had a new release since 2017,
so we decided to directly patch the contributed source.
Bug: #3426
devel/py-schematics-patched: Remove expired port
2026-09-24 devel/py-schematics-patched: Upstream inactive since +8 years. Please use devel/py-cattrs instead
contrib/flex: Guard against int overflow in sko_push().
sko_sz is an int; doubling it unchecked could overflow and produce a
huge size_t for realloc(). Bail out if it would overflow.
It's sad that the upstream project hasn't had a new release since 2017,
so we decided to directly patch the contributed source.
Bug: #3426
[TTI] Provide conservative legality + costs for @llvm.speculative.load. (#180036)
Add TTI support for @llvm.speculative.load, including cost and legaltiy
checking support.
The initial implementation for AArch64 checks if the loaded type is
<= 16 bytes, and only considers such cases legal due to MTE.
PR:
https://github.com/llvm/llvm-project/pull/180036
Depends on https://github.com/llvm/llvm-project/pull/179642
[clang-tidy] Fix redundant-branch-condition false positive in loops (#225827)
Fixes #205685.
`bugprone-redundant-branch-condition` decides whether the condition
variable changes between the outer and inner `if` by comparing source
positions. When a loop sits between the two, a mutation that comes after
the inner `if` in the source still runs before the inner condition is
evaluated again on the next iteration, so the check reports a redundant
condition that isn't, and the fix-it changes behavior.
The fix walks the parents of the inner `if` up to the outer `if` and
finds the outermost enclosing loop. If the variable is mutated anywhere
in that loop, the check does not warn. This follows NagyDonat's
suggestion in the issue: the existing check already covers mutations
between the outer condition and the loop, so only the loop itself needs
the extra query. The walk passes through declarations, so an inner `if`
inside a lambda stored in a variable is handled too, and it stops at the
enclosing function. I chose a syntactic walk instead of the CFG
[21 lines not shown]
libc: reject a negative wchar_t in the UTF-8 encoder
_UTF8_wcrtomb() and _UTF8_wcrtombin() pick the four byte form with
"wc <= 0x10ffff". wchar_t is signed, so every negative value passes
that test and is encoded from its low bits: wcrtomb() of (wchar_t)-1
returns 4 and writes ff bf bf bf, and printf("%lc", -1) prints those
bytes instead of failing with EILSEQ as it does for 0x110000.
Add "wc >= 0 &&" to both tests, as FreeBSD's utf8.c has.
GitHub-PR: https://github.com/DragonFlyBSD/DragonFlyBSD/pull/57
FreeBSD: https://github.com/freebsd/freebsd-src/commit/8bb93485fb51aac423ec000aa292815cf50bb02c
libc: type a positional %F argument in __find_arguments()
When a format uses positional arguments, __find_arguments() walks it
first to learn the type of every argument, and lists the floating
point conversions as a A e E f g G. F is missing, so a double that
is only referred to through %F never gets a type, its slot in the
argument table stays unset, and the conversion reads whatever is
there:
printf("[%1$F]\n", -INFINITY); [0.000000]
printf("[%1$F]\n", 1.5); [0.000000]
printf("[%F]\n", 1.5); [1.500000]
The same format with %1$f, or with any other conversion of the same
argument, works because those give it a type. abseil's str_format
test compares against the C library and caught it.
Add F next to f in both __find_arguments() and __find_warguments().
GitHub-PR: https://github.com/DragonFlyBSD/DragonFlyBSD/pull/56
gpt(8): Fix "expand" command to update 'hdr_lba_end'
Update the usuable LBA by fixing the 'hdr_lba_end' after expanding.
Otherwise, the extended partition may extend beyond the usuable LBA.
Bugs: #3276, #3423
p5-Email-Sender: update to 2.603.
2.603 2026-09-21 11:24:06-04:00 America/New_York
- Just re-issued to correct the CVE identifier for the issue fixed in
2.602: it is CVE-2026-93012.
p5-DateTime-TimeZone: update to 2.70.
2.70 2026-09-20
- This release is based on version 2026d of the Olson database. This release includes contemporary
changes for Canada's Northwest Territories.
