But overall even though I still use C almost daily, I'm a bit skeptical of the committee's direction with these changes. They added half assed generics through macros, now a defer mechanism and a bunch of other stuff that's, IMO, out of scope for C. People have already tried to make a "better C" with all these bells and whistles, it's called C++, and it's still mostly backward compatible with C.
IMO C should be considered to be in "maintenance mode" these days. And again, my IRL job involves writing a lot of it, so it's not like I don't care about it.
I hate the mess that c++ is. It started out with a object based programming paradigm with c like syntax. Then generics/templates were added. Then we have modern c++. It's 3 different languages crammed into one. The c++ committee has a serious case of nifty-itis.
__attribute__((cleanup)) gcc/clang extension already works without extra blocks. GLib has been using it for a while https://blogs.gnome.org/desrt/2015/01/30/g_autoptr/
Clearly, the C committee works hard on improving the language and they are in the process to standardize important features, such as lambda functions, auto, typeof (like C++'s decltype more or less), and so forth.
In my humble opinion, "defer" can mild the buffer / memory overflow, but of course not permanently remedied it 100%; to me though it's better to have such mechanism than have nothing at all to protect you.
https://gustedt.wordpress.com/2020/12/14/a-defer-mechanism-f...