Migrating to a pointer-size-pair string representation would be a better use of one's time.
Which is to say, is unrealistic for many programs.
C has an array type, it’s just a bit wacky, and it doesn't play by the same rules as other types.
The C standard committee has a general policy of not breaking code. If you want something like C with a better type system and less of the broken stuff (hello, arithmetic conversions) you can try Zig or one of the others. Once you’re okay with breaking code, you call it a different language, and go in trying to fix lots of things.
Unix V4 predates C standardization anyway.
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.
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.
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.
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?
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.
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.
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.
It's not like it's a flimsy tribal based claim, the guidance is solid.
The belief it was created alongside UNIX from the start, when it was used to port UNIX V4 into high level language.
Micro-optimizing each line of code as it is written, "because it is fast", without even bothering to use a profiler.
Even though lint was created alongside C to fix already known programmer faults using the language, in 1979, the belief that only bad programmers need such kind of tooling.
With the CPU, MMU and OS architectures of that period, it wasn't particularly hard to infer what was fast without profiling it. The slow rise in complexity at all 3 levels now makes it hard for even extremely experienced close-to-the-metal programmers to understand what will be fast or slow without a profiler. Times do change, in fact.
So it gets a cargo cult status like UNIX was only possible because C was designed to make it happen and other bogus pocus that ignores almost 15 years of previous work in high level languages for systems programming.
Ah, that makes sense, but that's a different cargo cult than Gibbon1 was complaining about.