On Mon, Mar 2, 2026 at 8:51 PM Pádraig Brady <[email protected]> wrote: > The INTEL_JCC_ERRATUM stuff may be more generally applicable,
That's right! Something like wc --lines also has a tight loop and might be also affected. That's worth benchmarking at the very least. I'm unsure if crypto hashes will be measurably affected. > and more appropriate for a separate patch. Should I maintain INTEL_JCC_ERRATUM for split(1) as a separate patch in the stack for now? > Was the issue with errnos in getlimits, too noisy logs? > We could disable tracing in getlimits_ if that was the case. The third patch is not for merging (yet?). It just sits in the stack as a quick hack to get around some compiler warnings (probably, "irrelevant and incorrect" as the commit message says). I've not looked at those issues carefully yet, but I'll try to. I've found a funny testcase for GCC while working on this code, those might be others. > It would be good to augment the "invalid rolling hash window" > error with a valid range for the selected hash. > Oh right I see there are other validations later on. > Anyway tt would be good to augment this initial error if possible. True, I'll take another look at error messages to make them less confusing. Some of them are, indeed, bad. -- WBRBW, Leonid Evdokimov, https://darkk.net.ru tel:+79816800702 PGP: 6691 DE6B 4CCD C1C1 76A0 0D4A E1F2 A980 7F50 FAB2
