Live data from Hacker News

C: Simple Defer, Ready to Use

gustedt.wordpress.com

71–80 of 157 posts

Re: C: Simple Defer, Ready to Use

#71

I'm a strong believer that if C had defer, many bugs would disappear. The number 1 issue I find myself having when switching from C++ to C is missing RAII (Main C++ way of implementing defer).

I agree about missing RAII when switching away from C++ but it seems like defer cleans up after enclosing function exits while RAII cleans up when object goes out of scope, which is more fine-grained. Maybe I'm misunderstanding exactly when defer would clean up but it seems more like a safety feature. As people pile more stuff into the function the cleanup would be deferred more and more while RAII encapsulates the m…

defer-based cleanup also has the problem that, if the function plans to return a value it has to make sure to *not* defer its cleanup, and the caller then has to remember to clean it up. Destructor-based cleanup avoids these problems, but of course it's reasonable for languages (existing ones like C and even newer ones like Zig) to not want destructors, so defer is the next best thing.

Note that C++ destructors are also not ideal because they run solely based on scope. Unless RVO happens, returning a value from a function involves returning a new value (created via copy ctor or move ctor) and the dtor still runs on the value in the function scope. If the new value was created via copy ctor, that means it unnecessarily had to create a copy and then destroy the original instead of just using the original. If the new value was created via move ctor, that means the type has to be designed in such a way that a "moved-out" value is still valid to run the dtor on. It works much better in Rust where moving is not only the default but also does not leave "moved-out" husks behind, so your type does not need to encode a "moved-out" state or implement a copy ctor if it doesn't want to, and the dtor will run the fewest number of times it needs to.

Re: C: Simple Defer, Ready to Use

#72
post #4

Do defers get processed if an exception is thrown? I know C doesn’t have exceptions, but real world C code often interacts with C++ code. So it is necessary imo to define that interaction. In C++ we have something pretty similar already in the form of Folly ScopeGuard (SCOPE_EXIT {}).

`extern "C"` functions coded in C++ should really not throw! I would say that they MUST NOT throw.

Re: C: Simple Defer, Ready to Use

#73
I once worked on a student robotics project where if you didn't gracefully shut down the connection to a specialized camera, it had a significant chance of physically bricking the camera.

We were using C++ and essentially instrumented code review processes, despite being a student group, to ensure nothing was ever called in a way where the destructor wouldn't be called - and broke out vision processing into a separate process so if other processes crashed we'd still be okay. In retrospect it was amazing training for a software engineering career.

But I always look at the words "simple" and "defer" and shudder when I see them next to each other!

Just like you'd have a "threat model" for cybersecurity, make sure you understand the consequences of a defer/destructor implementation not functioning properly.

Re: C: Simple Defer, Ready to Use

#74
post #43

Earlier quoted context omitted.

Fair, I was not explaining why the statement was wrong. Anyhow, the trampoline is not related to the call site being in the same function but whether a pointer is generated to the nested function and escapes. Nested functions in general do not need trampolines or executable stack.

Nice, if this is reliable across gcc versions and optimization levels, I might consider it for future stuff. Though making it such that treesitter and other tools dont barf on it would still need investigation.

I've used nested functions for a very long time with gcc and they are completely reliable. Since my code is embedded without an MMU the oh noes executable stack doesn't fill me with any dread.

It's unfortunate a lot of the standards guys are horrified by anything that isn't C89. Because if the executable stack is an issue it's worth fixing.

Side note: 20 years ago people thought if they made the stack non executable that would totally fix stack smashing attacks and unfortunately it only slows down script kiddies.

Re: C: Simple Defer, Ready to Use

#75

I'm a strong believer that if C had defer, many bugs would disappear. The number 1 issue I find myself having when switching from C++ to C is missing RAII (Main C++ way of implementing defer).

...and a we would get a host of new bugs that would be a lot harder to fix. Invisible jumps are very bad.

Nearly every modern language supports defer in some sense. Unless you are talking about RAII hiding the defer, but that's not the case with a custom Defer type or similar that takes a closure in the constructor.

Defer is a way better solution than having to cleanup in every single failure case.

Re: C: Simple Defer, Ready to Use

#76

I'm a strong believer that if C had defer, many bugs would disappear. The number 1 issue I find myself having when switching from C++ to C is missing RAII (Main C++ way of implementing defer).

The major source of bugs in C is located on string.h, and nothing has been made in 50 years to fix that.

Really fix, not mitigations with their own gotchas.

Re: C: Simple Defer, Ready to Use

#77
post #64
post #35

Unfortunately, nested functions are one of the few GCC extensions not implemented by clang, as such this really only works on GCC.

If this proposal is adopted in C2Y, surely Clang will implement it.

Most likely yes, although being on ISO doesn't mean much, there are plenty of examples of features that not every compiler fully supports.

Re: C: Simple Defer, Ready to Use

#79
post #65

Nobody knows about BOOST_SCOPE_DEFER? #include BOOST_SCOPE_DEFER [&] { close(fd); }; Implementation here: https://github.com/boostorg/scope/blob/develop/include/boost...

Only for those willing to stomach the entire boost hairball, which in embedded environments might be too much to ask.

Re: C: Simple Defer, Ready to Use

#80
post #30

Earlier quoted context omitted.

i like how the contraction it’s and abbreviation T’is are anagrams

It is not T'is, it is Tis. No apostrophe.

The word is 'tis with an apostrophe.

https://www.britannica.com/dictionary/%27tis

https://www.merriam-webster.com/dictionary/%27tis

https://dictionary.cambridge.org/us/dictionary/english/tis

Post reply on HN