Posts by thephd@pony.social
(DIR) Post #AzHDmr3ccSqVLmRWsa by thephd@pony.social
2025-10-16T19:11:19Z
1 likes, 0 repeats
"Remove const"OOOF, that's a SCALDING hot take. But it's kind of correct. "read-only" is like an object property, not really a good type-system property. But we don't have a good decl-based/object-based system in C (in fact, it has NO real good object model, which will come up later when talking defer); only compile-time system that exists in C is the type system, alas!"I'd remove const from C, but I'd have to replace it with something else." Yeah. It's too useful to get rid of outright, you'd have to replace it, unfortunately. Odin manages this slightly differently than C does."C is the wrong langauge to try and add immutability too" agreed, 100%. It's also why "functional programming" really struggles here, and why C++ struggled to make a functional library bit without some semi-dire consequences (C++20 filter_view shenanigans, anyone?).(They start talking about how overloaded static is, and they bring up the obscure [static N] bit in the language.)Yeah, that's awful. It's not a good way to do bounds, unfortunately! Being able to lie and not having a pre-packed way of keeping the size and pointer together is NOT good. I'm not saying you should never have the ability to lie or just have a naked pointer and attach a random size to it, but 99% of the time you want the system to carry the size and the pointer together, and it's effectively what you do with malloc since it stores it in either a specific block-size section in their heap or they store the size in some pre-determined place before the pointer they hand back to you, or in a pool somewhere!"I would remove the entire standard library" hard agree! C's standard library is its WEAKEST part. Very awful design, lots of shared, mutable, invisible state. Truly bad, very thread-antagonistic. Blowing it up and starting over would be very good stuff.But then it's not C. :3
(DIR) Post #AzHDmrnLsRQRdbq39s by thephd@pony.social
2025-10-16T19:13:35Z
0 likes, 0 repeats
"Only include memset, memmove, and memcpy" yeah, basically. That's pretty much all C is good for for its stdlib.The printing stuff sucks, the time stuff is dated and sucks, the thread stuff still sucks (I'm working on it), the atomics have some guarantees but not all, the Unicode stuff is now okay for conversions (but lacks support pretty much everywhere else), and so on and so forth. It's all booty-ass-cheeks, so, you know. Blow it up, start all over again, make sure it's multi-threading aware (NO internal locks/shared data), stuff like that!
(DIR) Post #AzHDmsXn5mZXxdZ8Xg by thephd@pony.social
2025-10-16T19:14:24Z
1 likes, 0 repeats
I need these people to talk to the C folks because SO MANY people in C-land are shooters for nul-terminated strings, and they are THE MOST crapshoot GARBAGE in C. But these two get it, BOTH the C lover and the C hater directly describe why the implicit-malloc, 0-terminated, threading-awful, and other such things in the standard library are AWFUL.(I also had this issue which is why I proposed SIZED thread attributes, but the Committee blew them all up and wanted null-terminated string ones only. So, even though these two people get it, other C people are EXTREMELY brain-poisoned on this subject and will die with their null-terminated strings despite the various issues that come with them. It's refreshing that even the younger C programmers understand how dogshit null-terminated is, though!)
(DIR) Post #AzHDmtLm5wYSSex3S4 by thephd@pony.social
2025-10-16T19:15:56Z
0 likes, 0 repeats
YEEEAH TALK YO SHIT, MALLOC SUCKS, CALLOC IS AWFUL, REALLOC IS GARBAGE, NO ALIGNMENT NO SIZES IT'S A "REALLY BAD API" THAT'S RIGHT BILL TALK TO 'EEEEEEEEEEEEM!!!!!!!!!!!!!!!!!!!!!!!!!!!!Everyone is agreeing that the whole C standard library design is shit. Good.There's hope for the youth yet."Memory management in C is not actually hard, NO! It's malloc that's hard!"Half-agree. Like, this is a complete true statement, but it's missing the "and we don't have good slices and everything's still a pointer"."Start with the most descriptive name, THEN compress it later." Bill and Ryan will be happy to know that we've adopted this policy! ... But mostly for very new features/headers. Old stuff will still probably have the compressed names! <stdbit.h> has descriptive names, though, as a recent example."We would remove most stuff from C23, and only work from C11 or C99/89" I've talked about this a lot previously, but honestly it's fine. This is how most C developers are; they consider the things they care about to be the holy grail, and then EVERYTHING else is FOR LOSERS.
(DIR) Post #AzHDmuLSObtXXxoJay by thephd@pony.social
2025-10-16T19:18:24Z
1 likes, 0 repeats
Good vouch for Bill's design chops, though:"In Odin, I have atomic operations, but I don't have atomic types but I've been considering the types."This is actually the correct direction of how to design atomics. Atomic operations are the fundamental, hardware-mirroring, low-level design. But then you put types on it for the same reason that Ryan advocated for shortened names: it's such a ridiculously common operation, and certain objects will never, ever be modified non-atomically, ever, and anytime you'd want the benefits of non-atomics you want it done safely from the comfort of an optimizing compiler that's proven all the bits necessary to just start doing shit non-atomically where it matters. C++ and C got this wrong in their designs, they started with atomic objects, but needed atomic "accesses" (operations).Linus also complained about this on the LKML, and C++ fixed it with atomic_ref in C++26. C has no fix for this, because it doesn't have references and because _Atomic(T)* and _Atomic T* are "pointer to atomic object T" and _Atomic(T*) is just "atomic pointer to object T" (e.g., just the accesses to the pointer are atomic). Not great.It is, unfortunately, something that is entirely unrepresentable in C at the moment. It needs to be fixed, but it won't for quite some time I'm sure because C is slow as balls to recognizing its mistakes and moving to fix them. Alas!
(DIR) Post #AzHDmvJMnroiXlq9ya by thephd@pony.social
2025-10-16T19:27:27Z
1 likes, 0 repeats
"I wouldn't have while, or do while, just for."I mean... I guess? Once you have one, the others are free. This is more nitpicky and honestly a flavor remove than anything, and he says as much, but. Even if I was designing a new language from scratch, it seems so totally.. free? Like it would cost me ~nothing to have while/for/loop in a new language. It's not even worth thinking about. If someone comes up with a fourth one that isn't well-handled by those three, then like, sure man. Spice it up. At some point I'd not have more, but. You know.This is one of those things that generates like 500-post-mailing-threads because it's such low-hanging fruit, so people will immediately start frothing at the mouth and bitching endlessly. It's a real timesuck; being a dictator means you can decide one way or another and then you can just start ignoring everyone who gets bitchy about it. It's not serious enough to matter, but BOY the amount people would bitch for or against it would make for legendary meltdowns.
(DIR) Post #AzHDmwBbYDCbFzDTW4 by thephd@pony.social
2025-10-16T19:34:58Z
0 likes, 0 repeats
"For language design, you do what people expect, not just pull stuff out of your ass." Again, good language design chops from Bill here. There's people who design what they want (and it fucking sucks to work with, like Java, Haskell, etc.) and then there's people who design for their users (C, Odin, C#, Typescript, Python, etc.)."Remove the arrow operator, just make the dot operator do the dereference."I mean. Kinda agree, but not really worth it now that the blood is already in the water. It's more important for C to do this than C++, cause no T&."I would remove uninitialized stuff. Equal-zero by design." Good stuff."Error handling in C?" Some disagreement between Ryan and Bill here. Ryan would might do implicit thread_local stuff, but Bill would do return types and keep it all locally. But Bill figures it's API stuff.Also talks about "partial success". He's not sure things are really cleaned up there.
(DIR) Post #AzHDmx7O5NQI9CFca8 by thephd@pony.social
2025-10-16T19:37:27Z
0 likes, 0 repeats
"Build syste-" YEAH NAH, NOT LISTENING ANYMORE, SKIP!!!!
(DIR) Post #AzHDmy4EYaUj5hmcIy by thephd@pony.social
2025-10-16T19:39:27Z
1 likes, 0 repeats
"My opinion on macros is that they're the only reason C has survived"Buddy you don't know the half of it. There's excel files using C macros as a preprocessing step. It's fucking bananas out there.
(DIR) Post #B0FoYGxnc1T1hxFrAe by thephd@pony.social
2025-11-14T21:46:24Z
0 likes, 0 repeats
I miss streaming
(DIR) Post #B0RqvRk2sVbspRNVKK by thephd@pony.social
2025-11-20T20:40:55Z
0 likes, 0 repeats
Didn't think it'd happen in the UT/DR community. Sucks hard.God bless and good luck to everyone who has to struggle through that. I'm so sorry.
(DIR) Post #B0oN6kHV35tvcESCzA by thephd@pony.social
2025-12-01T17:25:02Z
1 likes, 0 repeats
Of course GCC has separate C and C++ frontends, which means Nested Functions don't work in the C++ frontend. Of course it's like that!!!!!
(DIR) Post #B19Aa0eM3EPThAvVDc by thephd@pony.social
2025-12-11T14:55:20Z
0 likes, 1 repeats
Not all closures have the same design, and as it turns out?It means they all don't perform the same under various usages, either! A quick dive into the performance differences of Closures in C, using an old Donald Knuth program as the stress tester.Dive into the performance metrics and challenge a few assumptions along the way!The Cost of a Closure in C | The Pasture | https://thephd.dev/the-cost-of-a-closure-in-c-c2y
(DIR) Post #B1DLkBPSmG9G5er2Tw by thephd@pony.social
2025-12-13T18:35:19Z
0 likes, 0 repeats
wrote a long rant post, deleted it.probably more cathartic and then better than posting. hm.
(DIR) Post #B1EVUBMYNT5u0kSjFg by thephd@pony.social
2025-12-11T15:00:33Z
1 likes, 0 repeats
Defer has landed in Clang and will (probably, most likely) land for Clang 22! Should show up in Godbolt within the next 48 hours or so, too:https://github.com/llvm/llvm-project/commit/71bfdd13040328bc83b520d09eee847fd2b7f82c
(DIR) Post #B1YmC5bitAUBnbTBJo by thephd@pony.social
2025-12-24T02:29:30Z
0 likes, 0 repeats
Merry Early Christmas.Here's a paper that allows users to specify different branches of _Generic without getting type errors for that branch, AND not losing consistent type checking of all branches. (Heavily inspired by work and examples and relevant discussion from @uecker -- thank you!)https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Expression%20Evaluation%20and%20Access%20in%20_Generic.html
(DIR) Post #B1YmC747T4nKJxlNDc by thephd@pony.social
2025-12-24T02:43:05Z
1 likes, 1 repeats
Type-safe, checked branchesEvaluation of the input expression only onceNo errors on unused branchesPick three.
(DIR) Post #B1sqg5GD1r9CO9AB8a by thephd@pony.social
2026-01-02T19:01:23Z
1 likes, 0 repeats
Very fun reading comments like "Björkus is just trying to C++-ify C" and the evidence presented is a bunch of C-exclusive things I'm doing that C++ doesn't have.Fun to see accusations of not tamping down on undefined behavior when there's an entire "Slay Earthly Demons" series. I am even writing papers to do things like stop relying on implementation-defined/undefined behavior of the builtins for bit intrinsics (all accepted into C23 and C2y now), I am only person who's trying to stop spreading the array-style undefined behavior to more places (we recently accepted a proposal to add that undefined behavior into _Generic match now and I have to retroactively fix it) and I stood my ground against several vendors when they wanted Undefined Behavior in #embed if it didn't get used inside of an array initializer to prevent more UB from showing up during preprocessing.At some point I just have to realize that the attitude of C is detached from the actual work we're doing in C. Maybe I can write an article to correct those perceptions but it's a lot of work and damn I've got a lot of stuff to do, constantly trying to just say "no that's wrong, man, are you even paying attention?" is kind of annoying.
(DIR) Post #B1sqgDg1jkYKUXIuUS by thephd@pony.social
2026-01-02T19:03:22Z
0 likes, 0 repeats
How do I correct this perception of reality without writing 30 articles?
(DIR) Post #B34fgzSpSgd10ak61Q by thephd@pony.social
2026-02-07T01:37:31Z
1 likes, 0 repeats
C Meeting adjourned. Pretty much nothing I was happy about made it through, including things I did and did not work on. For the things I was responsible for...-- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20printf%20string%20size%20specifiers.htmlSized strings are not important to the Committee for C, and printf will remain printing with (int) casts. There was no direction to continue, but some said they'd change their vote if I implemented it and came back to show it was a low-cost, simple implementation.-- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Functions%20with%20Data%20-%20Closures%20in%20C.htmlClosures had some direction to continue but faces extreme opposition because (most) implementers want to either (a) ignore captures altogether and do something with no local state; (b) standardize no-captures and promise to do something maybe, later. Tough.All the other papers I was happy about on the agenda didn't get anywhere, and some of the issue resolutions went the way I didn't like, but it's not really worth mentioning because I'm not a Big Implementation (and apparently, not a Real C Person). Not much I say can matter.I think vendors want to close C down basically, as a sort of thermostatic backlash to the various changes being proposed and from so much being one in C23. I can't really stop that and it's unfortunately bad because there's various "simple" proposals that have long-term consequences.But we're not really illuminating those consequences in discussion or papers right now. I have a lot of papers right now that'd just be "there are betters ways to do this, please let's think about this" and I'm kind of tired just from thinking about it.Maybe I'll be a more effective advocate next meeting. Who knows.I also realize everyone is going to continue to clown on me as being a C++ person no matter how much expertise I have/gain in C, so I think I have to implement a compiler or do a complex renounciation-of-C++ post of something before people evaluate my work on its technical merits purely. It also doesn't help that most changes I am working on tackle significantly large areas that I always get "eww, C++" as a default reaction, even for things like defer, which is -- generally -- pretty annoying.Knee-jerk Anti-C++ hatred is wearing on me. Worst part is, nobody properly communicates what's C++-centric about anything we standardized, other than the spellings. They don't even read the history of their own features. E.g., __auto_type and auto coming from C first, because it was implemented for macro shenanigans while C++ was still goo-goo-gaa-gaa and using typedef typename foo::typename bar:: typename baz;-style crap and didn't realize the goodness of type deduction until 10 years after __auto_type was making for clean C macros. But no, no, it's a "C++ invention", and you can't convince them otherwise.Brutal to have to live with it and deal with.I'll figure something out, eventually.