Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Defer available in gcc and clang

gustedt.wordpress.com

Post reply on HN
Print view View original

231–240 of 262 posts

Re: Defer available in gcc and clang

#231

Post by lich_king »

robinsonb5 wrote: post #80
lich_king wrote: post #26

Earlier quoted context omitted.

> I still stay with C89 because I know it will be portable anywhere With respect, that sounds a bit nuts. It's been 37 years since C89; unless you're targeting computers that still have floppy drives, why give up on so many convenience features? Binary prefixes (0b), #embed, defined-width integer types, more flexibility with placing labels, static_assert for compile-time sanity checks, inline functions, declarations…

To be honest I have similar reservations. The one huge advantage of C is its ubiquity - you can use it on the latest shiny computer / OS / compiler as well as some obscure embedded platform with a compiler that hasn't been updated since 2002. (That's a rare enough situation to be unimportant, right? /laughs in industrial control gear.) I'm wary of anything which fragments the language and makes it inaccessible to sub…

> The one huge advantage of C is its ubiquity - you can use it on the latest shiny computer / OS / compiler as well as some obscure embedded platform with a compiler that hasn't been updated since 2002.

First, for all platforms supported by mainstream compilers, which includes most of embedded systems (from 8 bit to 64 bit), this is not really a concern. You're cross-compiling on your desktop anyway. You'd need to deliberately install and use gcc from the early 1990s, but no one is forcing you. Are you routinely developing software for systems so niche that they aren't even supported by gcc?

But second, the code you write for the desktop is almost never the code you're gonna run in these environments, so why limit yourself across the board? In most embedded environments, especially legacy ones, you won't even have standard libc.

Re: Defer available in gcc and clang

#232

Post by win311fwg »

mort96 wrote: post #230
win311fwg wrote: post #229

Earlier quoted context omitted.

Maybe, but why would one introduce coupling between the worker queue and the work being done? That is a poor design. Now we know why it was painful. What is interesting here is that the pain wasn't noticed as a signal that the design was off. I wonder why? We should dive into that topic. I suspect at the heart of it lies why there is so much general dislike for Go as a language, with it being far less forgiving to po…

I think your issue is that you're an architecture astronaut. This is not a compliment. It's okay for things to just do the thing they're meant to do and not be super duper generic and extensible.

It is perfectly okay inside of a package. Once you introduce exports, like as seen in another thread, then there is good reason to think more carefully about how users are going to use it. Pulling the rug out from underneath them later when you discover your original API was ill-conceived is not good citizenry.

But one does still have to be mindful if they want to write software productively. Using a "super duper generic and extensible" solution means that things like error propagation is already solved for you. Your code, on the other hand, is going to quickly become a mess once you start adding all that extra machinery. It didn't go unnoticed that you conveniently left that out.

Maybe that no longer matters with LLMs, when you don't even have to look the code and producing it is effectively free, but LLMs these days also understand how defer works so then this whole thing becomes moot.

Re: Defer available in gcc and clang

#233

Post by pjmlp »

LexiMax wrote: post #227
pjmlp wrote: post #87

Earlier quoted context omitted.

Because they are all the consequence of holding it wrong, avoiding RAII solutions. Working with native C APIs in C++ is akin to using unsafe in Rust, C#, Swift..., it should be wrapped in type safe functions or classes/structs, never used directly outside implementation code. If folks actually followed this more often, there would be so much less CVE reports in C++ code caused by calling into C.

> Because they are all the consequence of holding it wrong, avoiding RAII solutions. The reason why C++ is as popular as it is is in large part due to how easy it is to upgrade an existing C codebase in-place. Doing a complete RAII rewrite is at best a long term objective, if not often completely out of the question. Acknowledging this reality means giving affordances like `defer` that allow upgrading C codebases and…

You can use a function try block on the destructor, additionally thanks to C++ metaprogramming capabilities, many of these handler classes can be written only once and reused across multiple scenarios.

Yes, unfortunely that compatibility is also the Achilles hill of C++, so many C++ libraries that are plain old C libraries with extern "C { .... } added in when using a C++ compiler, and also why so many CVEs keep happening in C++ code.

Re: Defer available in gcc and clang

#234

Post by pjmlp »

layer8 wrote: post #216
pjmlp wrote: post #210

Earlier quoted context omitted.

While not automated, you can make use of function-try-blocks, e.g.: struct Example { Example() = default; ~Example() try { // elease resources for this instance } catch (...) { // take care of what went wrong in the whole destructor call chain } }; -- https://cpp.godbolt.org/z/55oMarbqY Now with C++26 reflection, one could eventually generate such boilerplate.

What I’m thinking of is that the C++ exception runtime would attach exceptions from destructors to any in-flight exception, forming an exception tree, instead of calling std::terminate. (And also provide an API to access that tree.) C++ already has to handle a potentially unlimited amount of simultaneous in-flight exceptions (nested destructor calls), so from a resource perspective having such a tree isn’t a complete…

I see, however I don't envision many folks on WG21 votting that in.

Re: Defer available in gcc and clang

#235

Post by dapperdrake »

uecker wrote: post #69
dapperdrake wrote: post #63

Earlier quoted context omitted.

Confer the recent bug related to goto-error handling in OpenSSH where the "additional" error return value wasn’t caught and allowed a security bypass accepting a failed key. Cleanup is good. Jumping around with "goto" confused most people in practice. It seems highly likely that most programmers model "defer" differently in their minds. EDIT: IIRC it was CVE-2025-26465. Read the code and the patch.

It is not clear to me that defer helps here. The issue is management of state (the return value) not control flow.

The return value depends on control flow ("obvious", please bear with me):

With "goto" the cleanup-up can jump anywhere. With "defer" the cleanup cannot really jump anywhere. It is easier to mentally stick to simply cleaning up in a common sense way. And taking care of multiple "unrelated" clean-up steps is "handled for you."

(Attacks on this sometimes approach complaints about lack of "common sense".)

Re: Defer available in gcc and clang

#236

Post by dapperdrake »

norir wrote: post #198

I have a personal aversion to defer as a language feature. Some of this is aesthetic. I prefer code to be linear, which is to say that instructions appear in the order that they are evaluated. Further, the presence of defer almost always implies that there are resources that can leak silently. I also dislike RAII because it often makes it difficult to reason about when destructors are run and also admits accidental l…

Failure is inherently "non-linear" in this sense, unless there is exhaustive case-analysis. That sounds a lot like "just never program a mistake."

Re: Defer available in gcc and clang

#238

Post by array_key_first »

qsera wrote: post #152
Galanwe wrote: post #148

Earlier quoted context omitted.

I don't understand why destructors enter the discussion. This is C, there is no destructors. Are you comparing "adding destructors to C" vs "adding defer to C"? The former would be bring so much in C that it wouldn't be C anymore. And if your point is "you should switch to C++ to get destructors", then it seems out of topic. By very definition, if we're talking about language X and your answer is "switch to Y", this…

Sorry, I had some other thread that involved destructors in my head. But the point is `defer` is still in "spooky action at a distance" category that I generally don't want in programming languages, especially in c.

But the real-world alternatives that people use are:

1. goto, which is "spooky action at a distance" to the nth degree. It's not even safe, you can goto anywhere, even out of scope.

2. cleanup attributes, which are not standard.

Re: Defer available in gcc and clang

#239

Post by remexre »

Joker_vD wrote: post #156
bashkiddie wrote: post #85

Earlier quoted context omitted.

I would like to second this. In Golang if you iterate over a thousand files and defer File.close() your OS will run out of file descriptors

Well, unless you're on Windows :D Even on Windows XP Home Edition I could open a million file handles with no problems. Seriously, why is default ulimit on file descriptors on Linux measly 1024?

https://0pointer.net/blog/file-descriptor-limits.html

Re: Defer available in gcc and clang

#240

Post by baq »

orlp wrote: post #30
gignico wrote: post #13

I’m just going to start teaching classes of C programming to university first-year CS students. Would you teach `defer` straight away to manage allocated memory?

In university? No, absolutely not straight away. The point of a CS degree is to know the fundamentals of computing, not the latest best practices in programming that abstract the fundamentals.

Absolutely the wrong take. You can teach CS with just pencil and paper, but that doesn’t advance the technology, it might only benefit academia in a narrow sense. CS students should be actively engineering software in addition to doing science.
Post reply on HN