Neither ISO nor OpenGroup would care about it.
Remember that since 1989, no actions were taken to improve its security.
Even the few functions that have been added still use pointer/length pairs without any means to validate they are the correct pair.
Not much, but not nothing, either. gets was deprecated in C99 and removed in C11 (https://en.wikipedia.org/wiki/C_file_input/output#gets)
Technically, gets() was removed from the standard library in C11[0]. However, that is far from a semantically meaningful overhaul of the standard library. I nonetheless felt the need to point out that there was a very specific effort for the sake of completeness.
Would it be easy enough to port important C code to it, given that most of the libc-supplied functions, and functions transitively depending on these, would have to be rewritten? Would it be worthwhile, compared to rewriting such code it in Zig, Rust, or Ada?
Only bothering to list two examples, there are many others, even Cyclone is partially C compatible, guess what came out of Cyclone.
import statements are a deal breaker
>C3
shit syntax
>Cyclone
vaporware
There's a Safe C++ extension proposed for Clang [0].
But those are C++, not C. A little different kettle of fish.
Gnome's Vala [1] aims to be the "smoothest C off-ramp". It does compile to C, but with GObject taking control of everything.
There's CheckedC [2], which adds optional bounds checking to C, and was backed by Microsoft until recently.
There's the Linux kernel's nolibc [3], which I've enjoyed the heck out of using, but it is rather constrained.
There's C's own Annex K [4], that almost nobody has implemented, and every compiler developer hates and can poke holes in. GCC and LLVM have both repeatedly said they won't support it. (So much as easy to get them to support things...)
GCC already has a number of memory safe languages, though. Most of which, because they're part of the same compiler suite, can interact with other languages that GCC has. Like the D or Go frontends.
[0] https://discourse.llvm.org/t/rfc-a-clangir-based-safe-c/8324...
[3] https://lwn.net/Articles/920158/
[4] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1106.txt
i mean, if the committee members can make it happen or not, i don't know. but it's still a worthy thing to explore, I think. there's going to be a lot of C code that will need a very gradual migration path to safer apis for a very very long time.