Hacker News Reader

Comment by rwmj | Hacker News Reader

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

View on HN

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!

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

What makes you think that this approach is only useful for resource-constrained circumstances?

Yeah it's reasonable. Unfortunately if you do it, and you run tools like Coverity, it'll produces reams of complaints about how you're leaking memory :-( There was one project which was genuinely a short-lived program that never needed to free memory, but in the end I gave in and added free() statements everywhere. Otherwise we could never have got it into RHEL.

Why not just put all the free()s at the end of main() behind an #ifdef DEBUG or something?

What are your issues with the memory requirements being small? One of the programs was a MUD that consumed a couple hundred megabytes, and I never had issues with it.

I mentioned gigabytes because of how mine specifically worked. It allocated chunks in powers of 2, so there was some % of memory that wasn't being used. For instance, If you only need 20 bytes for a string, you got back a pointer for a chunk of 32 bytes. Being just a game, and side project, I never gave it much thought, so I'm curious to hear your input.

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.

When something would normally be freed, it calls the memory manager's version of free(), which zeroes the memory and adds it back into the appropriate available list.

Isn't that just stacking your own allocator on top of the libc allocator, the same way the libc allocator is stacked on top of the OS's page mappings? It's often a sensible idea, of course, but I wouldn't describe it as "never freeing things", just substituting libc's malloc()/free() for your own. It's not like the libc allocator is doing something radically different from keeping lists of available and allocated memory.

libc allocator is considered "slow" for the extra overhead it has. I'll just leave it at that as you can GPT the rest. I did some of my own testing back in the days I wrote C, and mine was significantly faster than malloc/free.

It's also a way, I suppose, to ensure your program has the memory it needs, depending on how you design it. Mine basically allocates all the expected memory I need at the start, while still being able to grab more if it needs. This was more of an issue back when you shared a server with lots of others.

Of course the libc allocator is slow, it's designed as a one-size-fits-all solution that's poorly tuned for most workloads and often doesn't get substantially updated for decades. By writing your own, you aren't avoiding an allocator, you're just avoiding the libc implementation of an allocator.

(In fact, most libcs let you just redefine the malloc(), free(), and realloc() functions to point to your own allocator instead of the default one, so you don't have to rewrite all the functions calling them. E.g., the mimalloc allocator [0] can be configured as a drop-in replacement for the libc allocator.)

[0] https://github.com/microsoft/mimalloc

I guess I'm confused at this chain of responses, then. As I'm doing what you are already suggesting.

Re-reading your comment, about the "not really freeing anything" -- I beg to differ, as when you do a real free(), it frees up memory for any program to use. As I already mentioned one of the benefits is once you have control of who can use that memory and aren't risking it not being available - disregarding some program that constantly grows in memory.

when you do a real free(), it frees up memory for any program to use

This is an extremely naive description of not only what the libc free() function does, but also of how memory management works in general.

There are always details within details. The overall idea is easily understandable. You are being pedantic.

Your description reveals a complete lack of understanding, and pointing out someone's lack of understanding is not being pedantic. Your choice of wording—"real free()" and "any program"—misrepresents the inherent complexity of implementing an allocator and does a disservice to both those less experienced and to the discussion in this thread.

You're assuming a platform. There are not a great number of guarantees when it comes to free:

The free subroutine deallocates a block of memory previously allocated by the malloc subsystem. Undefined results occur if the Pointer parameter is not an address that has previously been allocated by the malloc subsystem, or if the Pointer parameter has already been deallocated. If the Pointer parameter is NULL, no action occurs.

All that is guaranteed, is a deallocation. Not how and when that memory will become available again.

Your "more detailed" understanding will break, and will cause headaches, on platforms ypu're not used to.

> you have control of who can use that memory and aren't risking it not being available

overcommit would like to have a word

You're just describing every allocator in the world, except many (most?) skip the zeroing part.

libc already does that. What is it that yours is adding?

I'd say 25 years ago you could write your own naive allocator, make just a couple of assumptions for your use case, and beat libc. But no more.

One of the selling points of Java in the 90s was the compacting part. Because in the 90s fragmentation was a much bigger problem than it is today. Today the libc allocators have advanced by maybe tens of thousands of PhDs worth of theory and practice. Oh, and we have 64bit virtual address space, which helps with some (but not all) of the problems with memory fragmentation.

See this post from Ian Lance Taylor about why Go didn't even bother with a compacting GC: https://groups.google.com/g/golang-nuts/c/KJiyv2mV2pU?pli=1

> Today the libc allocators have advanced by maybe tens of thousands of PhDs worth of theory and practice.

Have they, though? Looking at the blame on glibc's malloc.c, the most substantial change in the last 10 years has been the addition of memory tagging. Apart from that, I mainly just see a bunch of small tweaks to the tcache, fastbins, etc., and the basic logic is broadly the same as it was 20 years ago. Similarly, the MallocInternals wiki page [0] appears mostly as it did in 2016, except for some more explanations of the tcache added in 2018.

I can easily believe that lots of work has been done on malloc/free-style allocators, but from what I've seen of most libc allocators, they hardly stand at the forefront of this work. (Except for the ones that just vendor some standalone allocator library and keep it up to date. But that describes neither Windows nor Linux.)

And of course, if you're writing your own allocator, you can relax some of the constraints, e.g., you can drop most of the multithreading support and not have to fool around with locks and shared arenas and whatnot.

[0] https://sourceware.org/glibc/wiki/MallocInternals

> Today the libc allocators have advanced by maybe tens of thousands of PhDs worth of theory and practice.

For fun I wrote up a very basic memory manager and benchmarked it against free/malloc. On my Mac (M3) the manager was 3x faster. On a random kubernetes pod (alpine) it was 33x faster. Performance increases as memory size goes up.

If this is true, can some of your ideas be integrated into the standard libc allocator?

Well, not on MacOS, I imagine (you tell me which repository/mailing list they should send a PR to :p). Really Windows and MacOS seem like the places where a malloc replacement is generally quite useful (Windows is a particularly big offender in this regard, Windows malloc is abysmal - MacOS less so iirc but still pretty bad) - it's glibc that's somewhat of an outlier by being generally pretty good.

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

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)

> Last time I looked this was (golang-like) function scoped, not { } scoped, which means it's a bad idea.

Might have been the previous attempt from years ago, because being block scoped (unlike go) literally has its own section in https://thephd.dev/c2y-the-defer-technical-specification-its...

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

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

That is not, as far as I know, how __attribute__((cleanup)) works. It just invokes the callback when the value goes out of scope. So you can't have malloc return an implicitly cleanup'd pointer unless malloc is a macro, in which case you can do the same with a defer block.

Yeah that's why I said "in theory". You can't do that with the attribute today, but it'd be possible to add that behavior to a standardized variant of it.

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.

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.

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

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

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

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

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

    if complex_nested_condition {
       defer cleanup()   
    }

Even with scope-based defer, you can accomplish conditional defers easily enough. In a sane language, where conditions are expressions, you could just do:

    defer if complex_nested_condition { cleanup() } else { noop() }

In Go, you could do:

    defer func(run bool) {
      if !run { return }
    }(condition)

Which admittedly wastes stack space with a noop function in the false case, but whatever.

I feel like the number of times I've needed conditional defers is almost zero, while the number of times I've had to make a new function to ensure scoping is correct is huge.

Of especial note, 'mu.Lock(), defer mu.Unlock()' not being scope-based is the largest source of deadlocks in code. People don't use 'defer' because the scoping rules are wrong, code panics before the manual unlock call, and then the program is deadlocked forever.

> You cannot use it for values that you want to return from the function

I would say this is only half true. With some macro magic you can actually also return the values :)

https://github.com/systemd/systemd/blob/0201114bb7f347015ed4...

To be fair though, you probably meant without any such shenanigans.

You can just zero out the pointer variable with __attribute__((cleanup)) before returning its value (from a temporary copy of course).

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

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

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.

I agree. But if we follow that logic then any compiler specific feature of either or clang is fair game, even if it’s not standard. MSVC doesn’t support it when compiling in C mode, for example.

> But if we follow that logic then any compiler specific feature of either or clang is fair game, even if it’s not standard.

Well, yeah...

How do you think Annex K got in?

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

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.

That sounds like the kind of code that you want to be done with and never touch again. You can only dream of it not being buggy or catching up with the newest standard.

No it is more like the 10000 lines of code running in your washing machine, you will probably be updating it in the next year revision of the product.

It is quite common for this code to have all variables be global and just not have any heap allocations at all. Sometimes you don't even have variables in the stack either (besides the globals).

I much prefer the purely-mechanical washing machines for this reason.. Way less to go wrong..

It is not that bad, the code is easier than your average web server and it is usually only one CPU for consumer devices. It gets bad if:

1) You add embedded linux

2) You have multiple CPUs that need to communicate with each other.

3) Both of the above (then the complexity skyrockets)

(this happens in modern cars)

So basically if it has a full LCD display (instead of 7-segment with a few extra toggle lights) I don't buy it.

It is actually quite refreshing code to read and write, yes the quality is often bad, but it often feels like school projects where they are small enough you can hold the complete system in your head. And it usually doesn't integrate with anything else besides the eletronics in the board

static allocation is the recommended mechanism in embedded code for reliability reasons, you have thought about you worst-case allocation and accounted for it... right? Also fragmentation and dynamic behaviour are bad things when your code has to run "forever".

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.

The bad news is that C23 broke a lot of existing code[1]. We had to do a lot of work in Fedora to fix the resulting mess. [1] https://gcc.gnu.org/gcc-15/porting_to.html#c23

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!

> Note that the bool type is not the same as int at ABI level,

Huh. Wonder what the benefits of that are. Bools being ints never struck me as a serious problem. I wonder if this catches people who accidentally assign rather than compare tho....

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.

For accessing any post-1970s operating system feature (e.g. async IO or virtual memory) you already cannot use standard C anymore (and POSIX is not the C stdlib).

The libraries you listed are all full of platform-specific code, and also have plenty of compiler-specific code behind ifdefs (for instance the stb headers have MSVC specific declspec declarations in them).

E.g. there is hardly any real-world C code out there that is 'pure standard C', if the code compiles on different compilers and for different target platforms then that's because the code specifically supports those compilers and target platforms.

My argument is that using these non-standard extensions to do important things like memory management in a C library is malpractice—it effectively locks down the library to specific C compilers. I'm sure that's fine if you're writing to clang specifically, but at that point, you can just write C++. libfreetype & stb_* are used and continue to be used because they can be relied on to be portable, and using compiler-specific extensions (without ifdefs) defeats that. If I relied on a clang-specific `defer`, I'm preventing my library from possibly being compiled via a future C compiler, let alone the compilers that exist now. To me, that's the point of writing C instead of C++ for a library (unless you're just a fan of the simplicity, which is more of an ideological, opinion-based reason).

If this is the argument then the actual standardisation is useless. I primarily use windows so I’m affected by one of the major compilers that doesn’t support this feature. This is no different to saying “chrome supports feature X, and realistically has y% market share so don’t let the fact that other browsers exist get in the way”.

Call it a posix extension, fair enough. But if your reason for writing C is that it’s portable, don’t go relying on non portable vendor specific extensions.

It's not, and even if there's something in the standard, your compiler of choice might not support it yet.

It's the same thing with the web and browser vendors, there's a constant mismatch, browsers propose and implement things and they may get standardized, and the standard dictates new requirements which might get implemented by all vendors.

The point of standardisation is defining behaviour for the things that are implemented as exploratory improvements and should be implemented on the more conservative compilers.

It's your choice whether to target the standard or a few selected compilers, there's a cost for both options between being late to improvements vs the possibility of needing to revisit your code around each of the "extensions" you decided to depend on.

If in certain projects portability is somehow of upmost importance, then any discussion around looking through the standard's black box to reach out for new stuff is kind of useless.

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.

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

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

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

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

Running under MSVC implies I'm building on Windows. In reality I'm cross compiling with Clang.

It’s a shame that glibc is so badly designed that cross-compiling for Linux is only vaguely possible because Andrew Kelley moved mountains via Zig.

Disagree. It’s fine and trivially easy. It’s only hard for Linux people who build software for Linux first and only. Then have a shocked pikachu face when they need to run in a different environment.

mingw is radically more problematic than MSVC. Don’t use mingw.

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

Can you expand on this?

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.

Same object doesn't have to be contended if the reference count is sharing cache line with another reference count.

I've seen this happen in cases arrays of objects are allocated, ie one per thread, and then handed to a thread pool to work on.

Even if heap allocated, if the object is just a reference counter and a few pointers, the memory allocator can fit several of them next to each other causing them to share cache lines, which causes the performance issues with atomic operations.

Depends on implementation of things of course, but can be a pitfall.

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.

Reply on news.ycombinator.com