the vessel of morgannareading 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 :/
d@nny disc@ mc²@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
@astraleureka i do not buy the gcc hate
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
@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