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

A Defer Mechanism for C

gustedt.wordpress.com

Post reply on HN
Print view View original

151–160 of 248 posts

Re: A Defer Mechanism for C

#151

Post by scottlamb »

_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…

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

Re: A Defer Mechanism for C

#153

Post by dang »

hhas01 wrote: post #147

“What we are trying to accomplish…” See also: silk purse, sow’s ear.

We detached this comment from https://news.ycombinator.com/item?id=25420221.

Please don't post shallow or snarky comments to HN [1]. It is particularly damaging when talking to a genuine expert [2]. Having a user like rseacord commenting in threads like this is great for everybody. When you incentivize them to leave, you harm the entire community. Your other comment [3] was pretty insulting too (at the beginning); people don't serve on standards committees because of money.

[1] https://news.ycombinator.com/newsguidelines.html

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

[3] https://news.ycombinator.com/item?id=25420638

Edit: we've already had to ask you to stop posting in the flamewar style to HN, and you've been doing it repeatedly lately. Would you please review the guidelines and use HN as intended? I don't want to ban you.

Re: A Defer Mechanism for C

#154

Post by eqvinox »

rseacord wrote: post #135
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.

Please submit a proposal.

That's not an useful response to constructive criticism, and neither is it a good way to deal with user feedback when in a position in a standardization entity.

Re: A Defer Mechanism for C

#155

Post by pornel »

greatgib wrote: post #2

Despite being convenient,I have the feeling that it might be a bad idea. One of the key interest of C compared to more recent languages is that everything is explicit. With a finger you can follow the code as it runs and know exactly what is going on and when exactly. At the opposite, there is c++ that does a lot of things automagically. And it is often hard to understand why you suddenly get a segfault out of blue,…

"Explicit" in language design is catch-all term for several different things: https://boats.gitlab.io/blog/post/2017-12-27-things-explicit... (I highly recommend this article.) Defer is still manual and local, just less noisy and burdensome.

Just like every C feature: if you know how it's implemented (and optimized), you will know what is going to happen. All big C compilers already support stack frames and unwinding, so it's not even entirely novel functionality.

While you may object it's not entirely obvious how unwinding is going to be implemented, OTOH in functions with complex control flow it can be easier to understand which `defer`s are going to be run, as opposed to following nested `else` statements, or reasoning about the program state from all `goto cleanup` locations.

Re: A Defer Mechanism for C

#156

Post by gpderetta »

jcelerier wrote: post #120
yason wrote: post #54

Earlier quoted context omitted.

RAII is a special case of defer, due to how it abuses constructors and destructors to hook into the points of entering and exiting scope. You could write a RAII implementation in terms of defer but not the other way around. RAII doesn't help with a generic pair of init and deinit functions, such as malloc() and free() for example, unless you wrap your mallocs into "memory objects" or something. You can't do anything…

> You could write a RAII implementation in terms of defer but not the other way around. c'mon, here's the article from 2000 that introduces ScopeGuard : https://www.drdobbs.com/cpp/generic-change-the-way-you-write...

Right! And to be clear you cannot implement RAII in term of defer as RAII is lifetime based while defer is only scope based.

Re: A Defer Mechanism for C

#157

Post by coldtea »

josephcsible wrote: post #116
coldtea wrote: post #35

Earlier quoted context omitted.

That's still local at the scope level though, which is quite acceptable. Plus, to handle the free or the leak if you had forgotten to free a resource at the exit point would also require to "know its lexical nesting up to top level". Between goto and longjump and co, C has much worse non-local behavior than defer.

Goto isn't nonlocal. You know you'll only every jump from them, and that you'll only ever jump to the specified label.

The specified label is what makes goto no-local. You need to check the whole codebase to find out where you'll land.

By your definition only [1] "come from" would be non-local.

[1] https://en.wikipedia.org/wiki/COMEFROM

Re: A Defer Mechanism for C

#158

Post by _dh54 »

cesarb wrote: post #62
CyberRabbi wrote: post #3

I’ve always considered “defer” an inelegant kludge in comparison to RAII for automatic cleanup of resources. It’s surprising that the C standards committee is considering adding that to the language. Then again, nearly none of the syntactic C features post-C89 have been very compelling or widely adopted.

> Then again, nearly none of the syntactic C features post-C89 have been very compelling or widely adopted. That's Microsoft's fault; it's 2020 already, and unless things changed since I last looked, their compiler still doesn't have full support for the C99 standard. Even then, some of the C99 syntactic features have been somewhat widely adopted (at least when not compiling for Windows); off the top of my head, we h…

“Somewhat widely adopted” is not “widely adopted” :)

I see people tend to write C89+designated initializers but this is a code smell IMO. Initial data should always be 0, especially data that lives in BSS/data section.

Re: A Defer Mechanism for C

#159

Post by jcelerier »

steveklabnik wrote: post #146
DougBTX wrote: post #90

Earlier quoted context omitted.

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)

> I believe the situation is the same in C++,

in the specific case of shared_ptr, which are a small part of codebases, if they are even used - for instance an immense amount of C++ GUI programs use Qt which doesn't use shared_ptr-like ownership semantics but instead a tree-of-objects model which does not have this issue. In contrast in Java / C# any object that has a reference to another is at risk.

Re: A Defer Mechanism for C

#160

Post by _8ljf »

dang wrote: post #153
hhas01 wrote: post #147

“What we are trying to accomplish…” See also: silk purse, sow’s ear.

We detached this comment from https://news.ycombinator.com/item?id=25420221 . Please don't post shallow or snarky comments to HN [1]. It is particularly damaging when talking to a genuine expert [2]. Having a user like rseacord commenting in threads like this is great for everybody. When you incentivize them to leave, you harm the entire community. Your other comment [3] was pretty insulting too (at the beginning); p…

Honestly mate, just go ahead and delete my account.
Post reply on HN