Stupid Smart Pointers in C

http://blog.kevinalbs.com/stupid_smart_pointers

by seansh • 1 year ago

146 133 1 year ago

blog.kevinalbs.com

adrianN• 1 year ago

I wonder how that affects compiler optimization

dhsysusbsjsi• 1 year ago

and stack protection cookies

jcranmer• 1 year ago

Let's just say there's a reason the author is compiling everything with -O0.

pjdesno• 1 year ago

Note that this will probably cause branch prediction misses, just like thread switching does - modern CPUs have a return address predictor which is just a simple stack. I don’t think you can avoid this without compiler support.

rwmj7• 1 year ago

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/talloc/doc/html/libtalloc__tutorial...) or Apache's APR.

(I didn't include using reference counting, since although that is also widely used, I've seen it cause so many bugs, plus it interacts badly with how modern CPUs work.)

MrBuddyCasino• 1 year ago

__attribute__((cleanup))

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

rwmj7• 1 year ago

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 function scoped, which makes it more useful than Golang's defer.

[1] https://gitlab.com/nbdkit/nbdkit/-/blob/8b36e5a2ea331eed2a73...

maccard3• 1 year ago

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.

rwmj7• 1 year ago

It's so widely used by OS software that you're likely using already, that it's unlikely to be removed and much more likely to be standardized. This is in fact how standardization ought to work - standardize the proven best practices.

dietr1ch4• 1 year ago

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 without a large real cost other than fighting your ideals for getting this into the standard first.

flohofwoe3• 1 year ago

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.

shakna3• 1 year ago

Defer was almost part of the C23 standard, but didn't quite make it. They've slimmed and changed a few things, and it looks like it very much might be part of the next.

[0] https://thephd.dev/c2y-the-defer-technical-specification-its...

[1] https://thephd.dev/_vendor/future_cxx/technical%20specificat...

milesrout2• 1 year ago

C's main selling point is not standardisation. It was widely used before standardisation and only standardised because it was useful.

masklinn5• 1 year ago

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)

rwmj7• 1 year ago

Last time I looked this was (golang-like) function scoped, not { } scoped, which means it's a bad idea. My feedback was the committee should simply standardize the existing attribute / behaviour, as that is widely used already.

(EDIT: I'm wrong, see reply)

EPWN3D2• 1 year ago

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

milesrout2• 1 year ago

I desperately hope it is not added, Meneide throws a tantrum like he did about his Rust conference talk, and he leaves the C committee forever. He is a malign influence that is on record as saying he dislikes C and wants it to be replaced by Rust.

WalterGillman• 1 year ago

Was just reading about this one the other day. Well-defined behavior and it actually solves a problem. Conceptually, I can't say it is worse than variadic functions or setjmp.

legohead7• 1 year ago

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!

KerrAvon• 1 year ago

A venerable and completely reasonable approach for resource-constrained environments and/or programs with very small memory requirements (kilobytes).

nine_k• 1 year ago

Well, it's basically an implementation of a memory allocator.

But how did you determine what you could re-use? That's the hard problem, one that's equivalent to calling free() at the right time.

pajko• 1 year ago

There's a complete implementation available at https://github.com/Snaipe/libcsptr

cryptonector3• 1 year ago

Sure, but TFA is a very clever hack -- disgusting, yes, impractical and non-portable, true, subject to sad limitations -of course-, but genius and entertaining.

The "tl;dr" summary is that `free_on_exit()` replaces the caller's return address with a trampoline that calls a `do_exit()` function that frees all the memory marked to be freed "on exit", and it uses its own stack of cleanup handler closures so-to-speak. When returning all the allocations are freed and then the original return address is returned to.

forrestthewoods3• 1 year ago

Use __attribute__((cleanup)). It's available in GCC and Clang

Really, don’t do this, it’s a portability nightmare. If you’re going to write C stick to code that easy to run under MSVC.

rossy• 1 year ago

Running under MSVC is overrated and more trouble than its worth. Clang and mingw-w64 GCC work just fine for targeting Windows.

acbits• 1 year ago

https://github.com/acbits/reftrack-plugin

Hey, I wrote this GCC plugin to automate reference counting in C. Any bug reports welcome.

bch• 1 year ago

... plus [reference counting] interacts badly with how modern CPUs work.

Can you expand on this?

sweetjuly• 1 year ago

I'm not sure what the reference to "modern CPUs" is, but a common complaint is that most reasonable reference counting implementations suffer very badly under contention. Specifically, if an object's reference count is contended (an object is being accessed/its pointer copied by many threads), it's possible that incrementing and then decrementing the reference count can take several hundred cycles due to either cache lines ping-ponging between cores or relatively expensive remote atomics (some Arm CPUs, I believe, allow the memory system to execute atomic operations in caches themselves to try and cope with contention/avoid moving cache lines back and forth by simply leaving them in a shared cache).

In reality, your milage will heavily vary. If you don't have contention (you don't commonly share objects across multiple threads concurrently), it's likely that reference counting will perform very well. Whether this is the common case really depends on the kinds of software you write.

scoopr• 1 year ago

Oh well, maybe we'll soon have `defer`? [0]

[0] https://thephd.dev/c2y-the-defer-technical-specification-its...

usrnm• 1 year ago

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

fuhsnn3• 1 year ago

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()}

masklinn5• 1 year ago

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.

vbezhenar• 1 year ago

What's "drop trait" for C? There are no any traits in C.

ynik• 1 year ago

Destructors/drop have issues though:

* cannot return errors/throw exceptions * cannot take additional parameters (and thus do not play well with "access token" concepts like pyo3's `Python` token that proves the GIL was acquired -- requiring the drop implementation to re-acquire the lock just in case)

I think `defer` would be a better language construct than destructors, if it's combined with some kind of linear types that produce compiler errors if there is some code path that does not move/destroy the object.

abcd_f• 1 year ago

Hacky and not really fit for production for more reasons than one, but clever and nice nonetheless. Good stuff.

feverzsj• 1 year ago

Just C programmer's daily struggle to mimic a fraction of C++.

Joker_vD• 1 year ago

Wow, an actual, purposeful, and quite general return-pointer-smashing gadget, built right into the program itself. Just what any program written in C needs.

Tewboo• 1 year ago

Smart pointers in C often feel like trying to force a square peg into a round hole. They’re powerful, but without native language support like C++, they can lead to more complexity than they solve.

torlok2• 1 year ago

I've heard enough "C is superior to C++" arguments from game developers who then go and use header structs for inheritance, or X macros, enums, and switch statements for virtual functions, to know that more complexity isn't an issue as long as people feel clever and validated.

unclad5968• 1 year ago

I don't think they do those things for validation. They do those things for control. Even c++ game developers create there own entire standard library replacements.

dima55• 1 year ago

X macros can do tons of stuff C++ can't. And if you stick with C, you avoid mountains of C++ problems, even with all the stuff you're talking about.

qalmakka2• 1 year ago

Or rather, given that every relevant C compiler is also a c++ compiler, just compile as c++ and use std::unique_ptr? I love C but I just can't understand the mental gymnastics of people that prefer this kind of hacks compared to just using C++

kllrnohj• 1 year ago

There's a lot of either "I like to pretend C is simple and simple is good" or "C++ has things I don't like, so I will refuse to also use the things I do like out of spite". You see it all over the place here whenever C or C++ comes up.

procaryote2• 1 year ago

Using C++ while keeping people on a common subset of C++ features is very hard in practice. Google for example do a pretty extreme amount of restrictive code standard, training, linting and reinventing libraries to that end.

A lot of the motivation behind inventing golang seems to be to remove C++ toys, because it's too hard to get people to not use them if they're there.

shakna3• 1 year ago

Unfortunately, that's not true.

C is not 100% compatible with C++.

There's a whole heap of incompatibilities that you can hit, that will prevent a lot of non-trivial C programs from compiling under C++. Things like character literals being a char in C++ and an int in C. Or C allowing designated initialisers for arrays, but C++ not.

qalmakka2• 1 year ago

I know, but it's not incredibly hard to work with them to be fair. People have been mixing C and C++ for decades now, we know where the sharp edges are pretty well

afarah1• 1 year ago

See also the "arena allocator", which has been discussed here before: https://nullprogram.com/blog/2023/09/27/

I haven't used it personally yet, but it addresses the same issue with a different approach, also related to stack-like lifetimes.

I've used simple reference counting before, also somewhat relevant in this context, and which skeeto also has a nice post about: https://nullprogram.com/blog/2015/02/17/

p0w3n3d• 1 year ago

  I see undefined behaviours. 
  they walk 
  they talk 
  they [0?W0OF??0?r??reeBSD
  they don't know they're undefined.

queuebert• 1 year ago

C is the LS engine of programming languages. People love to drop it in and mod it until it blows up.

whatsakandr• 1 year ago

This article should of had the conclusion of this is why you should use arena allocator.

Dwedit2• 1 year ago

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.

flohofwoe3• 1 year ago

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.

dhooper• 1 year ago

This is the way

procaryote2• 1 year ago

It makes the code so much simpler. And quite probably faster as there's less malloc/free churn.

A lot of problems break down to:

* we need this effectively forever (i.e. until config reload)

* we need this very briefly when processing a task or request

Sometimes you need a cache that has intermediate lifetimes, but that is a much smaller problem to deal with, and you can often cope with manual memory management for that

Hook any file handles and other resource cleanup functions into the same pools and you have a pretty easy life.

qwertox• 1 year ago

Not to mention that any future CPU microcode update released in order to mitigate some serious CVE might break the entire product you've been shipping, just because it relied on some stack manipulation wizardry.

PeterWhittaker• 1 year ago

1) 2018

2) I recently discovered the implementation of free_on_exit won't work if called directly from main if gcc aligns the stack. In this case, main adds padding between the saved eip and the saved ebp, (example). I think this can be fixed some tweaking, and will update this article when it is fixed.

I do not believe the article was updated, suggesting that the "tweaking" was far more complex than the author expected...

...which doesn't surprise me, because the overall tone is one of a clever but far-less-experienced-than-they-think programmer having what they think is a flash of insight and realizing thereby they can solve simply a problem that has plagued the industry and community for decades.

cryptonector3• 1 year ago

Right, and then there's interactions with StackGuard-like features.

mac3n2• 1 year ago

this is way overkill

the way i do this in C looks like

    initialize all resource pointers to NULL;

    attempt all allocations;

    if all pointers are non-NULL, do the thing (typically calling another routine)

    free all non-NULL pointers

realloc(ptr, 0) nicely handles allocations and possible-NULL deallocations

mac3n2• 1 year ago

if you must have a `free_on_exit()` (for example, if you allocate a variable number of pointers in a loop) then build your own defer stack registering pointers using memory that you allocate

zabzonk2• 1 year ago

might as well free the NULL pointers as well - this is totally valid C and can simplify the code

wavemode• 1 year ago

I suppose the implication is that, checking for null allows your cleanup logic to be more complex than simply calling free()

for example, the object could be managing an open file, or an open socket

anacrolix• 1 year ago

The naive assumption is that shared_ptr is always better than manual tracking. It's not. Tracking and cleaning up resources individually is a burden at scale.

casenmgreen• 1 year ago

I maintain a combined error and resource state per thread.

It is first argument to all functions.

If no errors, function proceeds - if error, function instead simply immediately returns.

When allocating resource, resource is recorded in a btree in the state.

When in a function an error occurs, error is recorded in state; after this point no code executes, because all code runs only if no errors.

At end of function is boilerplate error, which is added to error state if an error has occurred. So for example if we try to open file and out of disk, we first get error "fopen failed no disk", then second error "opening file failed", and then all parent functions in the current call stack will submit their errors, and you get a call stack.

Program then proceeds to exit(), and immediately before exit frees all resources (and in correct order) as recorded in btree, and prints error stack.

ForTheKidz2• 1 year ago

Why bother freeing before exit?

lionkor2• 1 year ago

Assuming that this would include properly closing sockets, etc. which the OS doesn't do the same way you might want to

PortiaBerries• 1 year ago

Around 1994, when I was a nerdy, homeschooled 8th grader teaching myself coding I came up with something I was inordinately proud of. I had gotten a book on PowerPC assembly so using Metrowerks CodeWarrior on my brand-new PowerMac 7100 I wrote a C function with inlined assembly that I called debugf. As I recall, it had the same signature as printf, called sprintf and then passed that resulting string to DebugStr. But the part I was proud of was that it erased itself from the stack so when the debugger popped up it was pointing to the line where you called debugf. I'm still proud of it :-).

nanolith• 1 year ago

It's a clever use of assembler, but in production code, it's much better to use a bounded model checker, like CBMC, to verify memory safety across all possible execution paths.

jay-barronville• 1 year ago

Like many C hacks, this is a fun one, but hacks like this should absolutely be avoided for any serious C code–the magic is simply not worth the potential bugs!

cryptonector3• 1 year ago

PuTTY is written in a Duff's Device co-routine hack on steroids that I'm sure someone at one point said "should absolutely be avoided for any serious C code–the magic is simply not worth the potential bugs!"! And PuTTY is no small program, and it's very successful.

One person's hack-that-should-be-avoided-at-all-costs can be someone else's secret sauce.

devit2• 1 year ago

That's completely asinine since it can't be made to work properly with inlining (including LTO), architectures that use a shadow stack or don't use a frame pointer, and also ridiculously inefficient and requiring assembly code for all architectures.

Use C++ or __attribute__((cleanup)) instead.

epolanski• 1 year ago

Maybe it is.

Or maybe the asinine "thing", is some folks lack of text comprehension skills that can't distinguish an experiment from a best practice recommendation despite a title and content that clearly does not invite that.

kazinator• 1 year ago

This kind of approach of allocating objects to a context which is freed all at once is implemented in GNU obstacks.

lionkor2• 1 year ago

Managing memory in C is difficult and error prone. C++ solves this with smart pointers like std::unique_ptr and std::shared_ptr.

No, it does not. Smart pointers are useful to help model lifetimes and ownership, but the real killer feature is RAII. Add that to C (standardized) and you can make smart pointers, and any other memory management primitive you need. Smart pointers are not a solution, they are one of many tools enabled by RAII.

Stupid Smart Pointers in C

Related Stories