Notices by ThePhD (thephd@pony.social)

All programming does these days is fill me with incandescent rage. I should just transition fulltime to burntout malemom.

WideCharToMultiByte doesn't allow you to use the last two parameters for most code pages. Which means it's functionally fucking impossible for me to determine the success of a code page conversion.

And the docs refuse to mention this. I spent all this time testing, for what??

EPIC WIN: I was going to implement defer in tinycc but someone has already done it for me!

GREAT SUCCESS.

I have decided I'm going to add spice to the _Any_func feature: https://thephd.dev/_vendor/future_cxx/papers/C%20-%20_Any_func.html#design.voidptr

Let's see how this goes over in the Committee in August...

(please discuss, boost, etc, the usual)

I'm gonna go with %q probably

Apparently, a bunch of people do not know this (on other platforms, anyhow), so here's your pre-emptive C trvth nvke for the day:

A void* is not guaranteed to be big enough or the right representation for any function pointer type. That is not a guarantee all architectures have and not one the C standard has either.

It's why pedantic compilation yells at you for function pointer -> void* conversions.

Windows, and all POSIX machines, have this guarantee. Embedded almost never does, especially with space-conscious / multi-segmented data spaces.

Okay, C working draft finally done. That took way longer than expected but now we can write papers against the latest.

• Latest working draft (same link as ever): https://drive.google.com/file/d/12kNvH0aYJhe3ZPmBKH_Nk5maTfxH2lJv/view
• Latest editor's report (same link as ever): https://drive.google.com/file/d/1UhLdNB_Kdzn_M56CotYC_Dn0AjbDA2V7/view

I am still working on proper Diff generation that shows changes from C23 to Now in a proper PDF-diff, but that's going to take a bit more time..

String sizes as size_t (and otherwise) for printf: https://thephd.dev/_vendor/future_cxx/papers/C%20-%20printf%20string%20size%20specifiers.html

Nope. Not gonna lose it about stdio.h -- I need peace.

Now that I've had time to experience it:

diagnosing int main() {} as a "K&R prototype" is a bit too aggressive on Clang's end. I would understand diagnosing simply a declaration of int main();, but diagnosing a full definition that has no parameters and also features no K&R-style definition parameter list is diabolical work, lol.

A smarter diagnostic, especially for (inline) function definitions, would be to see if it features a K&R parameter list; if it does, error (because K&R is not supported). If it's just a naked declaration with whatever meow();, error. But definition with no K&R? Fine.

Writing a paper about my adventures with pthreads is gonna be great.

Surprisingly, it's not the Windows thread API that's awful, it's just pthreads.

pthreads is garbage.

Everyone has so, SO many pthread_foo_np -- where the np at the end stands for "nonportable" -- things to do bogstandard basic shit that it's infuriating, and even if you're working with "just" pthreads, in practice it's actually more fucked than just working with the win32 thread API or TlsAlloc.

POSIX just keeps churning out bad API after bad API.

It only gets worse, too. There's not just 1 way to spell "set name of thread" in pthreads.

There's fucking five.

• pthread_setname_np(pthread_t thrd, const char* name);
• pthread_set_name_np(pthread_t thrd, const char* format, const char* name); // ??? HUH
• pthread_set_name_np(pthread_t thrd, const char* name);
• pthread_setname_np(const char* name); // Apple doesn't let you pick the thread, because Of Course They Don't
• pthread_attr_setname_np(pthread_attr_t* attrs, const char* name); // This is the correct way, but only available on specific IBM platforms

I also haven't included ANY of the return values (because for some of them, it's different for some fucking reason).

These people couldn't design a good API if it spit on their face.

Clearly I haven't gotten enough of my 🍑 kicked by the standards process. So, here we go, doing Big Work all over again. The first of many larger changes for C that should've been done 25 years ago, since the days of __try/__finally.

Let's get it done. ⤵

The Defer Technical Specification: It Is Time | Björkus Dorkus | The Pasture | https://thephd.dev/c2y-the-defer-technical-specification-its-time-go-go-go

I guess this means I need to really accelerate the pace of building my own C compiler and becoming my own cornerstone in a niche community. I think I already ruined my chances of becoming a proper GCC or Clang contributor.

Before anyone takes this sideways:

It's a personal admission of fault. I don't think I have the guts to survive GCC and Clang's process for a lot of my smaller but honestly important fixes. They're also very strict on new additions, unless it's backed by a strong promise for long-term commitment, or it's proposed by a long-standing community member and goes through the suggestion process (e.g. the _Generic(type, ...) change that sailed into Clang and GCC and then got into C2y after like only a handful of months of implementation experience (which is good, I wrote about it and I like the change: https://thephd.dev/improving-_generic-in-c2y )).

But. Most large, flagship vendors are not really a good place to try experimentation, and the vendors are signaling pretty loudly they're not interested unless you're ready to Commit All The Way. So, maybe it's time I take on some burden myself and take things in a different direction.

Don't think tcc is worth it either; they've got a very specific vibe about how they want to do things, and kencc is likely off the map too. I hate to be That Guy, but yeah: I think I'm gonna need One More Implementation.

I gotta see so many posts saying "Rust is slower" and like I think these people just evaluate languages and designs based on vibes and not based on like the material output from the compilers.

Damn this is thicc!!

I can't read it yet but here's to making good progress on a better C compiler.

The damn survey has 950+ responses. If I get another burst it'll hit 1,000.

There's no way I can manually very every single entry, lol. Guess I'll have to use some basic general-checking techniques in a python script.

https://pony.social/@thephd/113659160563714508