reading a thread on the musl mailing list with a patch replacing the iswalpha/iswpunct functions with a compressed LUT, the code is clever, functional *and* better for the common cases, but the submitters replies very strongly smell of chatbot slop :/
@astraleureka what is a LUT
@hipsterelectron a lookup table
@astraleureka the facebook guy here saying yeah we decided to do things a nonstandard way https://www.openwall.com/lists/musl/2026/03/24/2 reminds me of zstd who has their own memcpy "WILDCPY" with safe 16 bytes of overwrite and then a week later i find they strictly benchmark in-memory
musl - Re: [SC22WG14.35974] N3849 - Memory allocation with size feedback v2, request for feedback

@astraleureka i do not buy the gcc hate

@astraleureka

To see why that's the case, consider a large vector of capacity C.

getting paid the big bucks to consider a large vector of capacity C

@astraleureka i definitely call bullshit on this lowercase k. pretty sure that is doing induction and then changing the counting variable into a rational
@hipsterelectron ohhh this is the {re,m}alloc with feedback thread.. i have been at least partially following this and the amount of bikeshedding glazed my eyes. i do not understand the motivation for fuzzy chance of slightly more space being returned from an allocation request when in the vast majority of cases you're going to need a whole lot more code on the consumer side to handle those cases where you get back more than you requested, isn't that going to eat up the really small number of cycles you could potentially "save" in the rare chance that you do get an expandable slice of memory that isn't already bounded by other allocations
@astraleureka oooh i buy your framing i'll read
@astraleureka yes wtf lmao
@astraleureka i'm a huge believer in scoped allocators as a conceptual measure just bc it's technically more information for the allocator to have a tagged set of users. but i also think i want a slightly more thoughtful and extensible way to handle those guarantees beyond rust's single scope at a time. i have been surprised that non lexical lifetimes were a solution to a problem
@astraleureka everything the fb guy is saying is weird and the intrinsic mention is funny when rust has this guy from google going yeah we do this crazy specific thing in llvm it's in the file that doesn't exist
NEON intrinsics are broken on big-endian · Issue #1484 · rust-lang/stdarch

These are currently broken because the order of elements inside vectors is reversed on big-endian systems: the ARM ABI requires that element 0 is located at the highest address of the vector type. ...

GitHub

@astraleureka

The C intrinsics work around this by reversing the element ordering in vectors before & after each intrinsic. We need to do the same in stdarch.

@astraleureka i do find the idea appealing
@astraleureka also it's crazy how andrew gallant cannot be broken
Make this crate build on big-endian aarch64. by he32 · Pull Request #162 · BurntSushi/memchr

As noted in rust-lang/stdarch#1484, the NEON intrinsics are broken on big-endian aarch64. This is part of fixing rust to build for & on big-endian aarch64, following up rust-lang/rust#129819.

GitHub