A Defer Mechanism for C • Hacker News Board

Re: A Defer Mechanism for C

#141

Post by _8ljf » Mon, Dec 14, 2020, 5:50 PM UTC

ludocode wrote: post #64

rwmj wrote: post #12

Please just standardize the already existing attribute((cleanup)) mechanism which is already being used by lots of Linux software. This new mechanism is incompatible while bringing no benefits.

I would tend to agree with you. Unfortunately this proposal is for much more than just block scope cleanup. This proposal contains a specification for complete stack unwinding in C. It doesn't just specify defer, but also panic and recover, which jumps between functions and cleans up guard blocks across stack frames. It's essentially exceptions for C. This is frankly horrifying and I can't believe the C standards com…

“I can't believe the C standards committee is entertaining this.”

Hey, standards committee’s gotta eat.

'defer'? I occasionaly use it in Swift to clean up resources; s’okay there, I guess, though I’m not convinced it’s better than Python’s 'with' block. But in C?

One of C’s few distinguishing strengths is that the language is relatively† small and stable, and well understood. For that kind of cleanup there is already 'goto', which again is small, stable, and well understood. I just used it for that the other day: it works, it’s fine; I’m a grown-up.

Yeah, sure, 'defer' is “safer” and “more elegant”… did we mention this is C? That ship sailed fifty years ago. Don’t try to make C into something it’s not: that’s C++’s job so go fill your boots there instead.

I just posted Tony Hoare’s excoriation of ALGOL68 the other day, but clearly it’s needed again:

http://zoo.cs.yale.edu/classes/cs422/2011/bib/hoare81emperor...

Simplest solution: track down the ruddy C standards committee and beat them in the head with a leather-bound copy of Zawinski's Law (wrapped around a large gold brick), till either they’re dead or they leave C be. It does what it was designed to do, and that along is reason enough not to dick with it just because they’re bored and struggling to justify their continued existence.

The only thing C needs to do is keep on working. That will only get harder the more crap they pile on top. A good artist knows when to stop.

Which brings us to…

“panic/recover”

K&R give us strength! Tell these frustrated wannabe language designers to go make their own damn language, instead of screwing up someone else’s!

Okay, now I’m done. And get off my lawn!

Re: A Defer Mechanism for C

#142

Post by dkersten » Mon, Dec 14, 2020, 5:50 PM UTC

gpderetta wrote: post #109

dkersten wrote: post #86

Earlier quoted context omitted.

I do feel that RAII is a little bit ruined by the fact that you cannot declare anonymous object instances. For example, I cannot write: lock (mutex); Expecting to declare an anonymous lock with the mutex passed in, as this gets parsed as a declaration of a lock called mutex (hopefully lock doesn’t have a default constrictor and I at least get an error). Instead I have to bake my lock: lock l(mutex); Often I have obje…

it is a bit annoying yes. There are some proposals to have a anonymous reusable placeholders like '_', but they haven't gone anywhere yet. You can do lock(mutex), some-lock-protected-expression; but it is a bit too cute and limited. On the other hand, being able to name the RAII object is often very useful for example if you need to dismiss them early, which happens often in transactional code (unlocking a mutex befo…

> On the other hand, being able to name the RAII object is often very useful

I didn't say it wasn't. Being able is perfectly fine, being forced is not. As I mentioned in another comment, the problem isn't the extra typing, the problem is that it requires us, the programmer, to remember to name it even when we don't feel we need and to remember that "foo (bar)" isn't calling the constructor of foo and passing in bar, its calling the default constructor and declaring bar. That's too many gotchas and rather error prone!

I believe there was a cppcon talk where the speaker said that it was a very common bug in Facebook, despite that they have linter rules to catch this case. Its also a rather insidious bug, because the code will run seemingly normally, just... it never actually locks anything. A rather hard problem to debug too.

Re: A Defer Mechanism for C

#143

Post by sesuximo » Mon, Dec 14, 2020, 6:02 PM UTC

asveikau wrote: post #136

sesuximo wrote: post #8

A nice alternative is to wrap malloc and give it a context argument. Then free via the context. This is really the same idea but doesn’t need any extra stuff in the language Or you know... free the things you need to free and move on with your life

That solution doesn't work if you malloc up a structure and stick other things that need cleanup and won't be aware of the context (example: a file descriptor) inside.

Maybe, maybe not.

If your context has a list of things to free, it can also have a list of things to close. Or whatever you want.

Many libraries do stuff like this and call the context creation/deletion lib_init/ lib_shutdown.

Re: A Defer Mechanism for C

#144

Post by _8ljf » Mon, Dec 14, 2020, 6:04 PM UTC

rwmj wrote: post #89

pjmlp wrote: post #66

Earlier quoted context omitted.

ISO has to care about much more platforms than just Linux.

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.

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].

Re: A Defer Mechanism for C

#145

Post by gpderetta » Mon, Dec 14, 2020, 6:05 PM UTC

dkersten wrote: post #142

gpderetta wrote: post #109

Earlier quoted context omitted.

it is a bit annoying yes. There are some proposals to have a anonymous reusable placeholders like '_', but they haven't gone anywhere yet. You can do lock(mutex), some-lock-protected-expression; but it is a bit too cute and limited. On the other hand, being able to name the RAII object is often very useful for example if you need to dismiss them early, which happens often in transactional code (unlocking a mutex befo…

> On the other hand, being able to name the RAII object is often very useful I didn't say it wasn't. Being able is perfectly fine, being forced is not. As I mentioned in another comment, the problem isn't the extra typing, the problem is that it requires us, the programmer, to remember to name it even when we don't feel we need and to remember that "foo (bar)" isn't calling the constructor of foo and passing in bar,…

yes, I think I hit it at least once and flagged I don't know how many times in code reviews.

Re: A Defer Mechanism for C

#146

Post by steveklabnik » Mon, Dec 14, 2020, 6:06 PM UTC

DougBTX wrote: post #90

cle wrote: post #71

Earlier quoted context omitted.

You’re missing the point. The two are alike in that something significant is happening that you as the programmer did not explicitly tell it to do. The specific mechanism really isn’t an important distinction here.

There is no guarantee when a Java finalizer will run, whereas a C++ destructor is guaranteed to run based on the code that you write. That's a big difference which has practical implications, using something with non-guaranteed behaviour as an example of why something with guaranteed behaviour is hard to predict seems like a misunderstanding.

I believe the situation is the same in C++, that is, if you have a shared_ptr cycle, the destructor will never be called, no?

It is more deterministic in C++, but you can still call exit(). (which is even more straightforward than the refcount cycle)

Re: A Defer Mechanism for C

#147

Post by hhas01 » Mon, Dec 14, 2020, 6:06 PM UTC

“What we are trying to accomplish…”

Re: A Defer Mechanism for C

#148

Post by cycloptic » Mon, Dec 14, 2020, 6:11 PM UTC

_8ljf wrote: post #141

ludocode wrote: post #64

Earlier quoted context omitted.

I would tend to agree with you. Unfortunately this proposal is for much more than just block scope cleanup. This proposal contains a specification for complete stack unwinding in C. It doesn't just specify defer, but also panic and recover, which jumps between functions and cleans up guard blocks across stack frames. It's essentially exceptions for C. This is frankly horrifying and I can't believe the C standards com…

“I can't believe the C standards committee is entertaining this.” Hey, standards committee’s gotta eat. 'defer'? I occasionaly use it in Swift to clean up resources; s’okay there, I guess, though I’m not convinced it’s better than Python’s 'with' block. But in C? One of C’s few distinguishing strengths is that the language is relatively† small and stable, and well understood. For that kind of cleanup there is already…

More features being added to a newer version of the standard doesn't prevent you from staying with the old version. Your trusty old C89 compiler will still continue to work.

Speaking from experience, GCC/Clang extensions are pretty useful when you can afford to use them and it would be nice to have some of that stuff standardized because a lot of code I see in the wild is already using them. The time for warning about C becoming a mess of incompatible extensions has already passed unfortunately, and the only group that can solve this is a standards committee.

Re: A Defer Mechanism for C

#149

Post by sloyd » Mon, Dec 14, 2020, 6:16 PM UTC

_8ljf wrote: post #141

ludocode wrote: post #64

Earlier quoted context omitted.

I would tend to agree with you. Unfortunately this proposal is for much more than just block scope cleanup. This proposal contains a specification for complete stack unwinding in C. It doesn't just specify defer, but also panic and recover, which jumps between functions and cleans up guard blocks across stack frames. It's essentially exceptions for C. This is frankly horrifying and I can't believe the C standards com…

“I can't believe the C standards committee is entertaining this.” Hey, standards committee’s gotta eat. 'defer'? I occasionaly use it in Swift to clean up resources; s’okay there, I guess, though I’m not convinced it’s better than Python’s 'with' block. But in C? One of C’s few distinguishing strengths is that the language is relatively† small and stable, and well understood. For that kind of cleanup there is already…

I couldn't agree more and created an account just to second your thoughts.

This is exactly why everyone hates using modern C++. Their standards committee has run amok with every fancy feature that every new language comes out with in the past two decades. And what has that wrought? A huge language that no one fully understands and is hard to read unless you happen to be the guy that wrote it and time since writing C is simplistically beautiful. I can write it and understand exactly what the assembly will look like on the backend of the compiler (with the exception of nasty macros). Don't mess with that. If it doesn't feel like it belongs, that's probably because it doesn't! Know when to stop.

Re: A Defer Mechanism for C

#150

Post by cycloptic » Mon, Dec 14, 2020, 6:20 PM UTC

ludocode wrote: post #64

rwmj wrote: post #12

Please just standardize the already existing attribute((cleanup)) mechanism which is already being used by lots of Linux software. This new mechanism is incompatible while bringing no benefits.

I would tend to agree with you. Unfortunately this proposal is for much more than just block scope cleanup. This proposal contains a specification for complete stack unwinding in C. It doesn't just specify defer, but also panic and recover, which jumps between functions and cleans up guard blocks across stack frames. It's essentially exceptions for C. This is frankly horrifying and I can't believe the C standards com…

>It's essentially exceptions for C. This is frankly horrifying and I can't believe the C standards committee is entertaining this.

I can because C already includes setjmp/longjmp as an exception mechanism that gets used in plenty of real code. The problem here is that those don't unwind the stack so they would break and cause memory leaks when using defer statements.