Notices by ThePhD (thephd@pony.social)

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

@linear Put a fake one in, I guess. I won't be using them for any real purpose except post at you if it seems your response is broken/incomplete.

This is closing in 5 days. Add your response to the mix as soon as possible, or risk never being heard in the Official Vote™!!

https://thephd.dev/the-big-array-size-survey-for-c

@navi @humm The process is here: https://www.open-std.org/jtc1/sc22/wg14/www/contributing.html

If you write the paper and the paper is clear in its rationale, I can present it at a Standards Meeting (as a Champion). This is a low-stakes way to make sure you can contribute; all you have to do is follow the steps at the URL up to writing and submitting a paper. They accept HTML, PDF, and TXT files usually. You can see papers here: https://www.open-std.org/JTC1/SC22/WG14/www/wg14_document_log

If you write the paper and want to present it yourself, you need to notify your (or rather, any) national body that you intend to be part of that National Body. You get one (1) free guest attendance so long as you just e-mail your (any) National Body to attend.

I say "your (any)" National Body because National Bodies are something that you can join, but the rules are set by the National Body. For example, I'm American but part of the Netherlands National Body thanks to a friend, so I attend as an "expert" through that body. There's someone who's from the Netherlands but attends as an American because their employer is part of the American National Body, INCITS.

You don't necessarily have to join the National Body that corresponds to your nationality/citizenry. I avoided the American one because they charge a steep fee even for individuals, per year. But sometimes the burecracy is too much and someone would rather just pay the American National Body to Be American. It is also easier to contact the American and Canadian National Bodies to just notify them you'd like to become part of the body, attend once, and then never actually join just so you can use your one (1) free guest attendance.

You have to register to attend, whether you show up in person or virtually. The next meeting is in Graz, Austria: https://www.open-std.org/JTC1/SC22/WG14/www/docs/n3399.pdf

@navi @humm If you are going to write a paper:

• Talk about the status quo ("how it works right now") for some code, typically using a few examples to show it
• Talk about the pros and cons of the status quo
• Show your change with a code example and what that means
• Finally, write wording against the latest Working Draft for how that change would work, in Standardese.

You can avoid doing the last one and just pitch the first part for the ideas and see if people like it. Add any existing practice from existing C compilers or other languages. Typically, C folks want to see strong existing practice, usually within C extensions. Other languages / C++ implementations together typically only count as "one" point for such altogether, whereas existing C extensions count for more per each implementation/vendor that ships said C extension. Usually the goal is to have 2 points, but if you explain hard enough you can overcome that depending on how much interest is shown and if there isn't any strong opposition,

Since I expect this to have opposition you may want to look into getting named parameters or something else into an existing compiler -- any existing compiler -- first, before you write the wording but after you write the paper.

Good Lucka nd God's Speed.

@navi @humm You're the third person to come up with that idea and tell me about it.

We can do it in C, because there's no function overloading in C. There's only one type that goes into the function, so we don't need the compound literal's type to know that { foo, nya, mew } goes into the function here. This would make function passing work very well, and e.g. sokol_gfx would be a lot easier to use because it makes extensive use of compound literals but the code looks quite a bit uglier for it: https://github.com/floooh/sokol/blob/master/sokol_gfx.h#L133

The problem is, people are annoyed that this would remove type information being explicitly visible for what they feel is not much useful gain. You'd have to go argue with those people primarily, and the best way to get them to say what they mean on the record is to write a paper for it.

I'm overbooked on work, so as much as I like the idea personally I can't write that sort of idea for you.

Similar, one could consider "named parameters" or something similar. Again, much easier to do in C because there's no function overloading, which means there's only one set of names. You might need to come up with a syntax to separate the name of the parameter from the name you want to expose.

Eitherway, good luck!

@navi @humm Finally. { foo, nya, mew } can't confuse the compiler because if you're not using .member = ... syntax, you're then just initializing things in declaration-order.

@luna I fucking hate C I fucking hate C I fucking hate C I fucking hate C I fucking hate C I fucking hate C I fuckingghgrwhj

A few days ago:
"Oh, I know, I'll release a little survey, I'm sure people don't care too much about what I say and/or write."

Today, checking back in:
... (* laughing nervously *)