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

Stupid Smart Pointers in C

blog.kevinalbs.com

Post reply on HN
Print view View original

31–40 of 174 posts

Re: Stupid Smart Pointers in C

#31

Post by UncleMeat »

bsenftner wrote: post #12
bsenftner wrote: post #6

[flagged]

[flagged]

I downvoted because in my mind you are winging it. "Just give it back" works well for simple cases, I suppose.

We observe that engineering teams struggle to write correct code without tools helping them. This is just an unavoidable fact. Even with tools that are unsound we still see oodles of memory safety bugs. This is true for small projects run by individuals up to massive projects with hundreds or thousands of developers. There are few activities as humbling as taking a project and throwing the sanitizers at it.

And bugs aren't "well you called malloc at the top of the function and forgot to call free at the bottom." Real systems have lifetime management that is vastly more complex than this and it is just not the case that telling people to not suck mitigates bugs.

Re: Stupid Smart Pointers in C

#34

Post by DanielHB »

dietr1ch wrote: post #29
maccard wrote: post #16

Earlier quoted context omitted.

> It's available in GCC and Clang, and we hope will be added to the C spec one day. This is widely used by open source software, eg. in systemd. It’s odd that the suggestion for a feature lacking in C is to use a non standard but well used supported path. c’s main selling point (IMO) is that it _is_ a standard, and relying on compiler vendor extensions kind of defeats the purpose of that.

> relying on compiler vendor extensions kind of defeats the purpose of that. Let's be honest, how many compilers are available, and how many of those would you actually use? The answer isn't more than 4 and the 2 compilers you are most likely to use among those already support this and probably won't stop supporting without a good alternative. I like standardisation, but you have to be realistic when it helps you wit…

There are quite a lot of embedded code that relies on obscure C compilers created and maintained by the CPU manufacturer.

But then again you are probably not doing a whole lot of heap management in embedded code.

Re: Stupid Smart Pointers in C

#35

Post by [deleted] »

rwmj wrote: post #5

Really, don't do this, it's a portability and safety nightmare (aside from C not being memory safe already). C programmers are better off with either of these two techniques: * Use __attribute__((cleanup)). It's available in GCC and Clang, and we hope will be added to the C spec one day. This is widely used by open source software, eg. in systemd. * Use a pool allocator like Samba's talloc ( https://talloc.samba.org/…

[deleted]

Re: Stupid Smart Pointers in C

#36

Post by amjoshuamichael »

dietr1ch wrote: post #29
maccard wrote: post #16

Earlier quoted context omitted.

> It's available in GCC and Clang, and we hope will be added to the C spec one day. This is widely used by open source software, eg. in systemd. It’s odd that the suggestion for a feature lacking in C is to use a non standard but well used supported path. c’s main selling point (IMO) is that it _is_ a standard, and relying on compiler vendor extensions kind of defeats the purpose of that.

> relying on compiler vendor extensions kind of defeats the purpose of that. Let's be honest, how many compilers are available, and how many of those would you actually use? The answer isn't more than 4 and the 2 compilers you are most likely to use among those already support this and probably won't stop supporting without a good alternative. I like standardisation, but you have to be realistic when it helps you wit…

For me, the point of writing something in C is portability. There were C compilers 30 years ago, there are C compilers now, and there will almost certainly be C compilers 30 years from now. If I want to write a good, portable library that's going to be useful for a long time, I'll do it in C. This is, at least, the standard in many gamedev circles (see: libsdl, libfreetype, the stb_* libraries). Under that expectation, I write to a standard, not a compiler.

Re: Stupid Smart Pointers in C

#37

Post by masklinn »

rwmj wrote: post #5

Really, don't do this, it's a portability and safety nightmare (aside from C not being memory safe already). C programmers are better off with either of these two techniques: * Use __attribute__((cleanup)). It's available in GCC and Clang, and we hope will be added to the C spec one day. This is widely used by open source software, eg. in systemd. * Use a pool allocator like Samba's talloc ( https://talloc.samba.org/…

> we hope will be added to the C spec one day

defer seems to be making significant progress (having a passionate and motivated advocate in Meneide, and a full TS)

Re: Stupid Smart Pointers in C

#38

Post by DanielHB »

fuhsnn wrote: post #30
usrnm wrote: post #20

Earlier quoted context omitted.

That's sad. Having migrated from C++ to golang a few years ago, I find defer vastly inferior to C++ destructors. Rust did it right with its drop trait, I think it's a much better approach

The proposed C defer is scope-based unlike Go. So in the spirit of OP article, you can basically hand roll not only C++ destructor as defer {obj.dtor()} but also Rust Drop as defer {obj.notmoved() ? Drop()}

What do you mean defer isn't scope based in Go?

(not super experienced Go developer)

Re: Stupid Smart Pointers in C

#39

Post by fpoling »

rwmj wrote: post #14
MrBuddyCasino wrote: post #9

Earlier quoted context omitted.

> __attribute__((cleanup)) Interesting. I'm not very proficient in C, this looks like some sort of finalizers for local variables?

Correct. You can use it in a simple way to free memory, but we've also used it to create scoped locks[1]. This being C, it's not without its problems. You cannot use it for values that you want to return from the function (as you don't want those to be freed), so any such variables cannot be automatically cleaned up on error paths either. Also there's no automated checking (it's not Rust!) Note it's {...} scoped, not…

While Go rules effectively prevents usage of defer in loops, it is useful occasionally to write:

    if complex_nested_condition {
       defer cleanup()   
    }

Re: Stupid Smart Pointers in C

#40

Post by masklinn »

usrnm wrote: post #20
scoopr wrote: post #7

Oh well, maybe we'll soon have `defer`? [0] [0] https://thephd.dev/c2y-the-defer-technical-specification-its...

That's sad. Having migrated from C++ to golang a few years ago, I find defer vastly inferior to C++ destructors. Rust did it right with its drop trait, I think it's a much better approach

Although that is true, the author has expounded at lengths on the unsuitability of RAII to the C programming langage, and as a big fan of RAII the explanations were convincing.
Post reply on HN