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

71–80 of 174 posts

Re: Stupid Smart Pointers in C

#71

Post by EPWN3D »

masklinn wrote: post #37
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)

defer is nice, but I really want the cleanup attribute since it could in theory by applied to the return type of a function. In other words you could have malloc return a pointer with the cleanup attribute that automatically frees it at end of scope if it's non-NULL. (And if you want to persist the pointer just assign to a different variable and zero out the one malloc gave you.)

Re: Stupid Smart Pointers in C

#72

Post by bsenftner »

minaguib wrote: post #54
bsenftner wrote: post #6

[flagged]

As someone who has been designing, writing, and operating high-performance systems for decades, I can guarantee you that it does not boil down to "laziness". Everyone starts with the best of intentions. malloc() and free() pairs. Then inevitable complexity comes in - the function gets split to multiple, then across modules, and maybe even across systems/services (for other shareable resources). The mental overhead of…

No, it is laziness, at the system architecture level. I've been doing this for decades too, in major corporations, writing the big name services that millions to billions of people use. The system architects are lazy, they do not want to do the accounting - that is all it is, just accounting of the resources one has and their current states, integrating that accounting tracking system into the environment - but few to none do, because it creates hard accountability, which they do not want. A soup of complexity is better for them, it grows their staff.

I've been playing this game long enough to see the fatal flaws built in, which grows complexity, staff, and the magnitude of the failures.

Re: Stupid Smart Pointers in C

#73

Post by bsenftner »

AnimalMuppet wrote: post #51
bsenftner wrote: post #12

Earlier quoted context omitted.

[flagged]

You can consider whatever you want. That doesn't make it accurate. The reason I downvoted was for unnecessary inflammatory language. Your point would have been better without it (more likely to be heard by the people you claim to be talking to, at a minimum). If you're actually trying to talk to people, if you're not just here to say "I'm smart and you're stupid" to gratify your ego, then why talk in a way that makes…

You are correct, and I seriously need to work on my language usage.

Re: Stupid Smart Pointers in C

#74

Post by dietr1ch »

amjoshuamichael wrote: post #36
dietr1ch wrote: post #29

Earlier quoted context omitted.

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

If I touch C it has to have control over allocations, memory layout, and wrapping low level code into functions I can call from other languages.

I'd target the latest C standard and won't even care to know how many old, niche compilers I'm leaving out. These are vastly different uses for C and obviously your gaols drastically change your standard or compiler targeted.

Re: Stupid Smart Pointers in C

#75

Post by Dwedit »

Highjacking the return address can only be done if you know you actually have a return address, and a reliable way to get to that return address. Function inlining can change that, adding local variables could change that, omitting frame pointer, etc.

It would also need to be a function that will truly be implemented as one following the ABI, which usually happens when the function is exported. Often times, internal functions won't follow the platform ABI exactly.

Just changing the compiler version is probably enough to break anything like this.

Save the return address highjacking stuff for assembly code.

---

Meanwhile, I personally have written C code that does mess with the stack pointer. It's GBA homebrew, so the program won't quit or finish execution, and resetting the stack pointer has the effect of giving you a little more stack memory.

Re: Stupid Smart Pointers in C

#76

Post by flohofwoe »

IMHO trying to emulate smart pointers in C is fixing a problem that shouldn't exist in the first place, and is also a problem in C++ code that uses smart pointers for memory management of individual objects.

Objects often come in batches of the same type and similar maximum lifetime, so let's make use of that.

Instead of tracking the individual lifetimes of thousands of objects it is often possible to group thousands of objects into just a handful of lifetime buckets.

Then use one arena allocator per lifetime bucket, and at the end of the 'bucket lifetime' discard the entire arena with all items in it (which of course assumes that there are no destructors to be called).

And suddenly you reduced a tricky problem (manually keeping track of thousands of lifetimes) to a trivial problem (manually keeping track of only a handful lifetimes).

And for the doubters: Zig demonstrates quite nicely that this approach works well also for big code bases, at least when the stdlib is built around that idea.

Re: Stupid Smart Pointers in C

#77

Post by legohead »

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

My C programs never consumed gigs of memory. So I (like many others I assume) made a memory manager and never freed anything. You'd ask it for memory and it kept a list of various sizes it allocated and returned what you needed to be re-used. Freeing and allocating is slow, and error prone, so just avoid it!

Re: Stupid Smart Pointers in C

#78

Post by fuhsnn »

rwmj wrote: post #69
fuhsnn wrote: post #62

Earlier quoted context omitted.

For the cases in linked doc, does adding -std=gnu17 to packages not suffice? I would consider the union initializer change (require adding -fzero-init-padding-bits=unions for old behavior) much more hidden and dangerous, which is not directly related to ISO C23 standard.

It's true that it does, yes. However that would still require changes to the build system. In any case for the vast majority of the packages we decided to fix (if you think this is a fix!) the code.

>if you think this is a fix

I would count it as doing maintenance work for the upstream, kudos for doing this!

Re: Stupid Smart Pointers in C

#79

Post by flohofwoe »

maccard wrote: post #16
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/…

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

Standard C is only the least common denominator that compiler vendors agreed on, and the C standard committee works 'reactively' by mostly standardizing features that have been in common use as non-standard extensions - sometimes for decades before standardization happens (this is probably the main difference to the C++ committee).

The *actual* power and flexibility of C lies in the non-standard, vendor-specific language extensions.

Re: Stupid Smart Pointers in C

#80

Post by Dwedit »

masklinn wrote: post #40
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

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.

Even Zig which is extremely against "Hidden control flow" (so no operator overloading, etc.) added in the "defer" feature.
Post reply on HN