int x, *p, arr[5], fn(), (*pfn)();

It's the intended way to read/write declarations/expressions. As a consequence, asterisks ends up placed near the identifiers. The confused ones will think it's a stylistic choice and won't understand any of this.

If they do what you suggest, all the creativity that makes the platform attractive is going to flock to somewhere else.

It does not provide a `resize`. You're thinking of `realloc` on hosted environments.

Therefore, my advice is to pretend you're a junior developer and do things the most naive way possible. Allow things to stink, to repeat code and to support just what's needed, as if this was the absolute final complete state of the application. This may lead to eventual refactors and this is healthy as the focus will be on correcting existing problems instead of foreseen ones.

This is when you allow your senior knowledge and experience to do what's necessary to return to a state that's comfortable for a junior. It's counterintuitive, but at the scale of a large codebase, the occasional refactors ouweights the time wasted doing preventing design at ever layer. I actually have a similar stance about defensive programming and testing.

Since this might not be enough to appease your brain, keep in mind that abstractions are generalizations trying to encompass some common 80%+ of cases, but they're usually never perfect and leave behind edge cases with additional complexity. Unfortunately, composing abstractions is multiplicative. 80%*80%=64%. Do it enough and your whole application becomes unsupported edge cases, constrainted to fit within interfaces, functions and types not able to adequetly give you the results you want and, so, you go crazy down the rabbit hole, trying to desperately break it down into even more suitable abstractions, like that's going to help.

There's a revenue threshold to meet to pay the fee.

You can read #13 of the Charter https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2086.htm

As for the audience, it's all the C developers, the open-source and commercial compiler implementations, vendors of libraries, tooling, services, learning material and everything else built in C; which is just innumerable.

Each Standard version released supersedes and obsoletes the previous versions. Intentionally, the versions are meant to be as backwards compatible as possible so that one can mix and match C89/C99/C11 codebases with minimum effort.

C has gained only a handful of features in the last 40 years. Compared to the great many things that are improved w.r.t. undefined/implementation-specific/unspecified behaviors, or removed to keep up with modern times (e.g. Trigraphs, Two's Complement integer representations, etc).

I'd say: (1) upgrading is not the spooky thing people make it out to be. Go, Rust, they all move much faster than this and have very ambitious big design ideas on their mind. (2) It's necessary to take good care of C as it, and the things built in it, will realistically outlive many of us.

https://news.ycombinator.com/newsguidelines.html

>> Off-Topic: Most stories about politics, or crime, or sports, unless they're evidence of some interesting new phenomenon. Videos of pratfalls or disasters, or cute animal pictures. If they'd cover it on TV news, it's probably off-topic.

There's a time and a place. I'm downvoting.

What jumps to the eye right now is that second option checked, as if that's the new feature.