News for hackers. Stuff that matters.
Re:A Defer Mechanism for C by pjmlp on Monday December 14, 2020 @10:17AM (#25418469)
ISO has to care about much more platforms than just Linux.
Re:A Defer Mechanism for C by rwmj on Monday December 14, 2020 @10:44AM (#25418804)
Which is why we want it to be standardized. It's already widely used on Linux and BSDs, the big compilers already implement the underlying functionality (because it's needed by C++), GCC and LLVM implement the exact same extension in an identical way, it does everything that people need, so let's make it work officially.
Re:A Defer Mechanism for C by pjmlp on Monday December 14, 2020 @12:33PM (#25420358)
Still there is a life beyond UNIX clones and gcc/clang.

The C compiler vendor for some embedded CPU with homegrown C compiler for their in-house OS also has a seat at ISO table.

While people here might not care, ISO does.

Re:A Defer Mechanism for C by cycloptic on Monday December 14, 2020 @06:11PM (#25424669)
The proposals generally exist so that compiler vendors can comment on them and try proof-of-concept implementations if they're interested.
Re:A Defer Mechanism for C by pjmlp on Tuesday December 15, 2020 @01:31AM (#25427626)
Indeed, and the fact that this is being proposed instead of adopting gcc/clang extensions, it is a proof that not all ISO members would be happy adopting that extension.
Re:A Defer Mechanism for C by rwmj on Monday December 14, 2020 @05:03PM (#25424005)
I agree. So go with the well-established widely used change, not the baroque and ill-defined proposal in the original post.
Re:A Defer Mechanism for C by _8ljf on Monday December 14, 2020 @01:04PM (#25420875)
So use C++ already; that’s what it’s for.

Don’t go complaining that C++ is “too complicated” and then be hauling its complexity into C, because all you’ll end up with is a bloated schizophrenic mess that is neither a good C nor a good C++ [alternative].