[klodolph]

> 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?

[pjmlp]

> 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.

[klodolph]

> 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.

[pjmlp]

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.