Too much kool-aid

Posted Feb 12, 2025 15:46 UTC (Wed) by alx.manpages (subscriber, #145117)
In reply to: Too much kool-aid by taladar
Parent article: Maintainer opinions on Rust-for-Linux

I fully agree that K&R C isn't a great language today. But GNU C2y is far from being K&R C.

Plan9 was also better than Unix in many ways, and we still use a Unix clone today. We have adapted it with the ideas of Plan9 (e.g., proc(5)). Plan9 was a useful experiment, just like Rust is useful today to backport improvements into C.

Linux is far from being a Unix V7/BSD/SysV clone, let alone Unix V1, just like GNU C2y isn't K&R C anymore.

Too much kool-aid

Posted Feb 12, 2025 20:20 UTC (Wed) by jmalcolm (subscriber, #8876) [Link] (1 responses)

Why are we calling it "GNU" C2y?

Unless I misunderstand, C2y is a placeholder for a C standard that does not yet exist. So, it is a bit of a weird place to make the argument around C maturity from to start with. I think C2y is expected to become C26 but it could easily be C27 or C28 (in 2028). It could be never. Being a "future" standard, the reference also supports the other side of the argument regarding the CURRENT state of the C language.

But, if that is what we mean by GNU C2y, I should point out that Clang has a C2y flag as well (-std=c2y). C2y is not a GNU standard. If anything, I would expect GNU C2y to refer to only the proposed changes to the current C standard that the GNU compiler has implemented.

How does limiting your reference to the proposed changes in C2y to the subset implemented in GNU software support your argument?

Too much kool-aid? Who are we referring to?

Too much kool-aid

Posted Feb 12, 2025 20:49 UTC (Wed) by alx.manpages (subscriber, #145117) [Link]

By GNU C2y I refer to -std=gnu2y, so a mix of ISO C2y with GNU extensions.

While GCC has not yet merged some changes, there are patches for them which will likely be available in the next version of the compiler. Most of those changes will be backported to older dialects (so available if you specify -std=gnu17), so while they're not written in stone in the standard, and are not already available in GCC, they will be very soon available in all GNU dialects, as *stable* features.