[uecker]

The C standard library does not have containers, so I do not see how this sentence makes any sense. The reality is that C++ STL is in practice not really safer than C arrays, and although you can activate bounds checking, there remain many gotchas. But I am happy to see that bounds checking is now becoming official with C++26. For C arrays you get bounds checking in practice with -fsanitize=bounds. For containers, you would need a library in C that does bounds checking. So in both languages it is possible to get bounds checking if you want to.

[pjmlp]

A compiler extension only available in clang is not C, so nope, there is no solution available in ISO C, and apparently never will be one.

Also to note that said extension only exists because Apple did the work WG14 did not bothered to do for the last 40 years, and as way to improve interop with safe Swift.

[uecker]

The compiler extension is also available in GCC at least, and it was you who cited extensions.

[pjmlp]

Doesn't change the fact that isn't on ISO C.

At least WG21 eventually did the correct thing and placed those extensions into the standard, even if due to governmental pressure.

Also while enabling bounds checking has been a common configuration option in all C++ compilers, clang and GCC aren't all C compilers.

This kind of discussion is also quite telling that nothing will change on WG14, maybe eventually who knows, C2y might finally get fat pointers if voted in, and then we will see during the following decades whatever fruits that will bare.

[uecker]

That WG21 made finally made its containers safer is great, but the C standard library does not have containers. You can still have your own bounds checked containers just fine in C, as you could in the past.. ISO C simply does not matter as much as you like to pretend - for trolling I must assume.

When we will have a standard for bounds checking arrays and pointers remains to be seen, but this does not stop anyone from using the non-standard tools available today.