Who mentioned anything about breaking existing code?

I already decided in 1992 that I don't want to use a broken language, unless when obliged by university work or work requirements.

Unfortunely I have to use software written by people that don't share that opinion and apparently WG14 also has a general policy that improving C safety doesn't matter.

> Who mentioned anything about breaking existing code?

You did, when you proposed writing &array[0] to get the address to the first element of an array.

Or maybe I misunderstand what you wrote, in which case you could clarify.

> Unfortunely I have to use software written by people that don't share that opinion and apparently WG14 also has a general policy that improving C safety doesn't matter.

What would WG14 be doing differently if they didn’t have this “policy”? Isn’t the obvious explanation that their top priority is to maintain compatibility with existing code? Is this explanation not satisfactory?

It seems absurd—in the extreme—to expect a standards committee to break large swaths existing code to improve safety, in a language with such a large amount of legacy code such as C. I would expect that if the standards committee chose to do that, compilers wouldn’t implement it and users wouldn’t use it. If you are going to break existing code, why not use a different language?

> You did, when you proposed writing &array[0] to get the address to the first element of an array.

That would only happen in two cases:

1 - If C arrays had been properly designed in first place,

2 - Since it is too late for 1 unless we happen to have a DeLorean parked around the corner, by introducing a new datatype for new code, just like happened to bool and complex on C99.

This is basic compiler design stuff that surely the WG14 heads are capable of.

If not, the Microsoft team from Checked C project can gladly explain to them how to extend C with new array types, while keeping compatibility with existing code.

I really don't get your "maintain compatibility with existing code" hot discussion.

> This is basic compiler design stuff that surely the WG14 heads are capable of.

What I don’t understand is why WG14, specifically, should be doing this. In my mind it seems obvious that WG14 just shouldn’t care about fixing deep issues with C—issues that would require high amounts of engineering effort to adopt. A new array type certainly falls in this category. C99 introduced VLAs—not even really a new array type—and these were so poorly adopted that VLAs were made optional in the next revision. You might also consider Annex K, which is also quite poorly adopted.

If you want to use Microsoft’s checked C, you can use it. If you want to use MISRA, you can use that. If you want to use formal methods, there are various subsets of C that you can tackle with formal methods. If you want to use asan, tsan, valgrind, or switch to Zig or Java or Rust, all of those options are available.

The problems with adding a new array type to the language are that:

1. If WG14 makes a change like you suggest, it will be poorly adopted, meaning that it's a poor fit for the standard, (just based on the history of the adoption of things like VLAs and Annex K, this is the most likely outcome).

2. You can just use a different language for new projects, or extensions / tooling for existing projects.

In other words, it’s a low value change with a high cost.

> I really don't get your "maintain compatibility with existing code" hot discussion.

It’s because your original comment was so short and vague. Feel free to ignore the responses, since you’ve since clarified.

WG14 is responsible for defining what C compilers are supposed to compile as language standard, available everywhere that C is supposed to be available and many times the only option availalbe.

Your suggestion to use something else is a bit hard on platforms where C is the name of the game.

I am mostly C clean since 1992, unless required otherwise, not everyone is free to chose their tooling, nor what language the software they use, e.g. UNIX kernels or IoT junk, was written on.

I think zig just blew a big gaping hole in the argument that the language needs to be tied to legacy code.

Because zig can compile old C code and Zig into the same binary. Which means there is no reason you couldn't compile old legacy C code and new better C code into the same binary as well.

The C standards committee need to be fired and replaced with people who aren't willfully holding the language back.

Hm, I can understand where you’re coming from but I think you’re asking for something which provides negligible value and would require a significant amount of engineering effort. Additionally, the way in which you’re expressing your opinions about the C language is needlessly inflammatory. What’s most unreasonable about your comment is the way it attacks people.

It seems like your issue here is really nothing more than the names of languages—your position is that there should be a language with clean semantics, interoperability with C, etc. and this language should furthermore be called “C”. A language exists—Zig—which seems to meet all your requirements except one. The only missing requirement, as far as I can tell, is that it is not called “C”. Let me know if there is something I misunderstand about your position, because I can’t think of a different way to interpret it.

I can see where you’re coming from—but to be honest, unless I am misunderstanding your position, your position seems completely unreasonable, and again, the personal attacks are pointlessly inflammatory.