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

161–170 of 174 posts

Re: Stupid Smart Pointers in C

#161

Post by epolanski »

alextingle wrote: post #70
jcranmer wrote: post #52

Earlier quoted context omitted.

We have 50 years of experience of code telling us that, no, programmers are not consistently capable of avoiding memory safety just by being good about it. Saying that it's just a failing of lesser programmers is the height of extreme arrogance, since I guarantee you that you've written memory safety vulnerabilities if you've written any significant amount of C code. The problem is not that the rules are hard to foll…

Is your function body really 600+ LOC?? If so, then I think I might have found your problem...

My experience reading lower level languages suggests me that this is not only possible but it seems that the higher the quality of the project (in scope, authors, products) the more of those you find.

When people focus on the _right_ implementation for _their_ problem they often find out that best practices like DRY or abstractions don't scale well at all.

Re: Stupid Smart Pointers in C

#162

Post by [deleted] »

bsenftner wrote: post #72
minaguib wrote: post #54

Earlier quoted context omitted.

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

[deleted]

Re: Stupid Smart Pointers in C

#163

Post by epolanski »

bsenftner wrote: post #72
minaguib wrote: post #54

Earlier quoted context omitted.

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

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

Renee Descartes, a brilliant philosopher and scientist always used to say that if he thinks A and the rest of the world thinks B, the wrong one is probably him. And he was one of the most brilliant humans we've ever produced!

Mind you, don't misread that as "you should act like a sheep" but in the opposite sense, that even if you're 100% certain others are wrong, you should still have the mental acumen to understand that probability isn't stacked in your favour.

People aren't burning their professional (or even hobby) time for years or decades working on tooling and languages that help in memory management just to help other's skill issues.

They find it an issue that needs better solutions, and that's it in C.

Re: Stupid Smart Pointers in C

#164

Post by ynik »

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

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.

Re: Stupid Smart Pointers in C

#165

Post by legohead »

thwarted wrote: post #141
legohead wrote: post #139

Earlier quoted context omitted.

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

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.

Re: Stupid Smart Pointers in C

#166

Post by legohead »

knorker wrote: post #118
legohead wrote: post #113

Earlier quoted context omitted.

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.

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

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

Re: Stupid Smart Pointers in C

#167

Post by thwarted »

legohead wrote: post #165
thwarted wrote: post #141

Earlier quoted context omitted.

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.

Re: Stupid Smart Pointers in C

#168

Post by fc417fc802 »

rossy wrote: post #142
forrestthewoods wrote: post #128

Earlier quoted context omitted.

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

Re: Stupid Smart Pointers in C

#169

Post by throwaway2037 »

legohead wrote: post #166
knorker wrote: post #118

Earlier quoted context omitted.

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

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

Re: Stupid Smart Pointers in C

#170

Post by shakna »

thwarted wrote: post #167
legohead wrote: post #165

Earlier quoted context omitted.

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.

Post reply on HN