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

Defer: Resource cleanup in C with GCCs magic

oshub.org

Post reply on HN
Print view View original

31–40 of 99 posts

Re: Defer: Resource cleanup in C with GCCs magic

#31

Post by lelanthran »

jcupitt wrote: post #6
pwdisswordfishz wrote: post #5

I don't understand why people insist on simulating a poor substitute for RAII with a feature that is itself almost decent RAII. > If malloc fails and returns NULL, the cleanup function will still be called, and there’s no simple way to add a guard inside free_ptr. free(NULL) is a no-op, this is a non-issue. I don't know what's so hard about a single if statement anyway even if this were an issue.

`free(NULL);` will crash on some platforms that gcc supports, I believe.

> `free(NULL);` will crash on some platforms that gcc supports, I believe.

I'm pretty certain that `free(NULL)` is part of the C99 standard, so compiler vendors have had 25 years to address it.

If your `free(NULL)` is crashing on a certain platform, you probably have bigger problems, starting with "Compiler that hasn't been updated in 25 years".

Re: Defer: Resource cleanup in C with GCCs magic

#32

Post by babel_ »

mgaunard wrote: post #26

Just use C++, it's its main feature on top of C.

> on top of C.

If we're referring to the "C is a subset of C++" / "C++ is a superset of C" idea, then this just hasn't been the case for some time now, and the two continue to diverge. It came up recently, so I'll link to a previous comment on it (https://news.ycombinator.com/item?id=45268696). I did reply to that with a few of the other current/future ways C is proposing/going to diverge even further from C++, since it's increasingly relevant to the discussion about what C2y (and beyond) will do, and how C code and C++ code will become ever more incompatible - at least at the syntactic level, presuming the C ABI contains to preserve its stability and the working groups remain cordial, as they have done, then the future is more "C & C++" rather than "C / C++", with the two still walking side-by-side... but clearly taking different steps.

If we're just talking about features C++ has that C doesn't, well, sure. RAII is the big one underpinning a lot of other C++ stuff. But C++ still can't be used in many places that C is, and part of why is baggage that features like RAII require (particularly function overloading and name mangling, even just for destructors alone)... which was carefully considered by the `defer` proposals, such as in N3488 (recently revised to N3687[0]) under section 4, or in other write-ups (including those by that proposal's author) like "Why Not Just Do Simple C++ RAII in C?"[1] and under the "But… What About C++?" section in [2]). In [0] they even directly point to "The Ideal World" (section 4.3) where both `defer` and RAII are available, since as they explain in 4.2, there are benefits to `defer` that RAII misses, and generally both have their uses that the other does not cleanly (if at all) represent! Of course, C++ does still have plenty of nice features that are sorely missing in C (personally longing for the day C gets proper namespaces), so I'm happy we always have it as an option and alternative... but, in turn, I feel the same about C. Sadly isn't as simple to "just use C++" in several domains I care about, let alone dealing with the "what dialect of C++" problem; exceptions or not, etc, etc...

[0]: https://www.open-std.org/JTC1/SC22/WG14/www/docs/n3687.htm [1]: https://thephd.dev/just-put-raii-in-c-bro-please-bro-just-on... [2]: https://thephd.dev/c2y-the-defer-technical-specification-its...

Re: Defer: Resource cleanup in C with GCCs magic

#33

Post by inkyoto »

mrheosuper wrote: post #10
jcupitt wrote: post #6

Earlier quoted context omitted.

`free(NULL);` will crash on some platforms that gcc supports, I believe.

can we just do `if(*ptr == NULL) return;` ?

If «ptr» is not a valid pointer, an attempt to dereference it (i.e. *ptr) will most assuredly crash the process with a SIGSEGV.

Re: Defer: Resource cleanup in C with GCCs magic

#34

Post by lelanthran »

mgaunard wrote: post #26

Just use C++, it's its main feature on top of C.

> Just use C++, it's its main feature on top of C.

If you want to and/or can, then go ahead. This is for those people who either don't want to, or can't, use C++.

Are you suggesting only use C++ over C in all situations?

Re: Defer: Resource cleanup in C with GCCs magic

#35

Post by ncruces »

masklinn wrote: post #27
ncruces wrote: post #15

Earlier quoted context omitted.

> I don't understand why people insist on simulating a poor substitute for RAII with a feature that is itself almost decent RAII. RAII doesn't make sense without initialization. Are you proposing C should add constructors, or that C should make do without defer because it can't add constructors?

> RAII doesn't make sense without initialization. Rust has RAII and does not have constructors.

Rust mandates that every field in a user-defined type is initialized at once. How do you propose to retrofit that into C without "constructors"?

Re: Defer: Resource cleanup in C with GCCs magic

#36

Post by knorker »

inkyoto wrote: post #33
mrheosuper wrote: post #10

Earlier quoted context omitted.

can we just do `if(*ptr == NULL) return;` ?

If «ptr» is not a valid pointer, an attempt to dereference it (i.e. *ptr) will most assuredly crash the process with a SIGSEGV.

But when would it not be a valid pointer, and yet also not a null pointer? A null pointer we can check for easily.

Re: Defer: Resource cleanup in C with GCCs magic

#37

Post by knorker »

menaerus wrote: post #22
mrheosuper wrote: post #20

Earlier quoted context omitted.

I'm not quite familar with this flag, but this >so that if a pointer is checked after it has already been dereferenced, it cannot be null. sound to me that if i've never deref the pointer anytime before(e.g the null check is at the beginning of function), the compiler won't remove this check.

Since the compiler will merge/fold what it appears to be a different logic sections of your code into a single one, you can never be sure what the release build codegen looks like unless you read the assembly.

If you check for null pointer before you dereference, then no the compiler cannot elide the check.

If you check after dereferencing it, yes it can. But in this case why would you not check before dereferencing? It's the only UB-free choice.

Re: Defer: Resource cleanup in C with GCCs magic

#38

Post by 1718627440 »

babel_ wrote: post #32
mgaunard wrote: post #26

Just use C++, it's its main feature on top of C.

> on top of C. If we're referring to the "C is a subset of C++" / "C++ is a superset of C" idea, then this just hasn't been the case for some time now, and the two continue to diverge. It came up recently, so I'll link to a previous comment on it ( https://news.ycombinator.com/item?id=45268696 ). I did reply to that with a few of the other current/future ways C is proposing/going to diverge even further from C++, sin…

> personally longing for the day C gets proper namespaces

I think in the spirit of C, this should go into the linker, not in the compiler.

Re: Defer: Resource cleanup in C with GCCs magic

#39

Post by 1718627440 »

pwdisswordfishz wrote: post #5

I don't understand why people insist on simulating a poor substitute for RAII with a feature that is itself almost decent RAII. > If malloc fails and returns NULL, the cleanup function will still be called, and there’s no simple way to add a guard inside free_ptr. free(NULL) is a no-op, this is a non-issue. I don't know what's so hard about a single if statement anyway even if this were an issue.

Not having RAII is precisely the reason I prefer C over C++ or Rust. I WANT to be able to separate allocation from initialization.

I'm currently working with Arduino code and the API is a mess. Everything has a second set of manual constructor/destructor, which bypasses type-safety entirely. All only to shoehorn having existing, but uninitialized objects into C++.

Re: Defer: Resource cleanup in C with GCCs magic

#40

Post by pjmlp »

fuhsnn wrote: post #25
scoopr wrote: post #4

Then there is the proposal to add standard `defer` to C2y[0] [0] https://thephd.dev/c2y-the-defer-technical-specification-its...

It's been implemented in GCC(in review)[1], onramp[2] and my own slimcc[3]! [1] https://patchwork.ozlabs.org/project/gcc/list/?series=470822 [2] https://github.com/ludocode/onramp [3] https://github.com/fuhsnn/slimcc

A good example of adding stuff to the standard with community feedback from a preview implementation.
Post reply on HN