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

@astraleureka holy shit

It doesn't take a rocket surgeon to figure out that an allocator- aware std::vector would be a marriage made in heaven:

@astraleureka this is remarkable

C++'s assumption of non-relocatable values hurts everybody for the benefit of a few questionable designs

@astraleureka using template structs and not concepts in TYOOLinus 2026? you are going to lose subscriber!
@astraleureka OMG they mention their fucking meme memcpy at the bottom
@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.

@hipsterelectron What the Fuck
@hipsterelectron completely unrelated but oh shit I know Amanieu from way back in the day, he used to be active in the tremulous (q3 full conversion mod) community back in like 2006-2009
@astraleureka he made a rust PR that was unrelated to this in 2023 changing tons of architecture directives across the repo and then went to the ahash repo and said sorry you broke the nightly i didn't release yet with no title or description so i find him curious but i actually have to admit the blue green is a really nice color
@hipsterelectron back in the trem days he authored the most popular qvm (quake VM) patchset for better moderation and game config tools, he was a pretty crucial part of keeping that community alive after the official devs kinda fell off
@astraleureka that sounds kind of unbelievably cool
@hipsterelectron it was a pretty magical time imo, several thousand players all over the world, fully open source game, it's where I cut my teeth on real world C and fleshed out sysadmin skills. my biggest accomplishment during that time was sql integration into the server to manage user tracking and logging. nowhere near what the actual wizards like amanieu or lakitu7 were up to though.
the game is pretty much undead these days, few servers still up but generally 0 players :(
@hipsterelectron I was also a really notorious forum troll in the community too so there's a lot to be embarrassed about, reading my old posts is So Bad
@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
@hipsterelectron @astraleureka This is even true in GCC.
Though GCC does not do this: "The C intrinsics work around this by reversing the element ordering in vectors before & after each intrinsic" Instead it only swaps around the inserts/extracts for generic vectors.
@pinskia @hipsterelectron how bad is the extra swapping in terms of instruction count? probably not *that* bad but has to hurt a little bit
@pinskia @astraleureka he didn't point to a real file!!! it is generated by the build system and does not seem to work this way. i would indeed be very glad to have one fewer thing to worry about and one more to learn about
@pinskia @astraleureka i do like being able to breathe
@pinskia @astraleureka that's why i found it such a dissatisfying explanation i didn't know at all how abstract it was
@hipsterelectron honestly it read like parody to me, either I am really ignorant and don't understand the issues at the depth they're discussing (very likely) or they're literally bickering about a completely synthetic scenario that has no practical chance of being useful in the real world (also seems to be kind of likely.....)

@hipsterelectron like. yes allocs are *relatively* expensive, but that can be amortised by design in the vast majority of cases, no?? if you're parsing a format or a protocol that really does leave you in the dark as to the potential size of buffers needed until the very last moment, that sucks, but that thankfully isn't the only scenario that exists??? trying to play games with handing out little extra servings on an allocation seems to run against the much more common case where the allocation is sized (semi)ideally up front or you're in an environment where the buffer can be doubled if needed, or whatever.

also i have a whole load of other questions about how this unexpected baker's allocation (extra bytes cuz ur such a good consumer) would play out in environments where pointers aren't just dumb (e.g. MTE), i think that gets brought up in the thread a few times but i don't remember what was actually said and frankly i'm not diving into that tonight

@hipsterelectron lol I didn't even see this thread, I only get like 50% of mail delivered by openwall lists because they don't rewrite mail from domains with DKIM quarantine/reject
@hipsterelectron cannot take the google guy named "Charles Munger" seriously without thinking about the berkshire hathaway guy instead. dead oligarch is submitting patches from beyond the grave
@hipsterelectron but yeah in the general case there's some very interesting discussions on this list, i enjoy reading about the intricacies of libc implementations, it isn't very high volume but it doesn't irritate me like the glibc list tends to for some reason