[uecker]

Basically any code that does not use pointer arithmetic or raw pointer dereferences and instead puts string handling and buffer management behind abstractions.

The new feature we will put in are not to enable safe programming, but to make it more convenient and to make safety demonstrable.

And I wish there was actually some real industry interest to pushing this forward. Industry seems more interested into claiming this an unfixable problem and we all have to switch to Rust, which gives them another decade of punting the problems with existing code.

[pjmlp]

So basically no examples, just hope people actually follow best practices, as usual.

Why doesn't WG14 prove the industry wrong then?

[uecker]

I could help with searching some public examples if you really do not know any code that uses safe string abstractions in C. But my original aim was to understand what specific "legacy cruft" in C is seen as problematic, and why its presence requires an entirely language to fix. So far, I did not get a good answer to this. I certainly do know some legacy cruft I want to see go but its presence does not prevent me from writing bounds-safe code.

WG14 is a very small number of volunteers. It would help if the industry would actually invest development resources for safety on the compiler / language side and in cleaning up legacy code.

[pjmlp]

Exactly, there are very few pearls of best practices in C, and those that exist, are probably in high integrity computing, with the relevant certification costs.

When all major OS vendors, some of whom are also compiler vendors, see more return into investment, contributing their money to alternative language foundations, or open source projects, than sending their employees to either WG14, or WG21, it is kind of clear ISO isn't going the way they would like to.

I would not call this an exaggeration, rather not listening.

Additionally, it would not surprise me if one of Zig, Odin, Rust eventually started popping up on console DevKits, or Khronos standards as well.

[uecker]

I don't know. WG21 is very big. WG14 is very small, so it is different. But in neither there is ISO going in some direction. Whoever shows up can influence the standard. Some of my proposals towards safety were opposed by compiler vendors because they do not want to put up too much pressure on their customer upgrading their legacy code. But of course, rewriting the code in another language would be much more effort than maintaining it... So I think the true answer is that nobody want to invest in maintenance of legacy code. But this will increasingly also be a problem for other languages once they are not young anymore.