Hacker News Reader

Comment by ludocode | Hacker News Reader

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 committee is entertaining this.

They claim that this is a separable feature from defer, so maybe they intend for defer to be mandatory and panic/recover to be optional. But much of the design of defer is to support their panic/recover mechanism. This makes it much more complicated than attribute((cleanup)). If they want defer to be taken seriously, they should move all of the panic/recover stuff to a separate proposal. I suspect if they did this, a lot of the design recommendations they've made for defer wouldn't make sense on their own.

View on HN

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

If you're already using setjmp/longjmp I would suspect you are also already using an arena or avoiding heap allocations, so I don't know if it would specifically be a problem for memory leaks with defer.

Doing other things in the proposal is no argument against having an attribute((cleanup)) compatible syntax for the part that overlaps.

Also, the defer syntax they're proposing seems nicer in terms of syntactic sugar (no need for a stub function), but at the same time the semantics seem ... weird. Having it tied to a variable makes more sense, and sidesteps a whole bunch of weird situations (like loops with defer statements).

In the contrary, I find it really weird to bind all cleanup code to some kind of object with constructors and destructors. People seem to have gotten so used to this ... I think that for C it is much more natural to have a control structure in the language for this.

“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!

This seems really strange to me. The C committee recently seemed pretty opposed [1] to adding fat pointers [edit: originally wrote bounds checking but that was a thinko] as eg WalterBright has called for. [2] Addressing that seems like it'd have a lot more benefit for a much smaller change to the language. I don't really agree with you on "the only thing C needs to do is keep on working" but if they're not willing to entertain that proposal, why on earth would they be talking about throwing in exceptions?

[1] https://news.ycombinator.com/item?id=22866288

[2] https://news.ycombinator.com/item?id=24454369

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 < two weeks.

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.

> This is exactly why everyone hates using modern C++.

speak for youreself ?

> 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?

given the amount of languages that reimplement C++ features (and sometimes have to be dragged by the feet to get them, e.g. generics and interface methods in java), I'd say that people who don't understand c++ are doomed to reinvent it :)

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.

Reply on news.ycombinator.com