Hacker News Reader

Comment by aninteger | Hacker News Reader

This is really neat, but I actually wonder if we aren't trying to solve a mostly solved problem.

As a C programmer, yes, sometimes you forget to free memory that you've allocated, but then you run valgrind or some other leak checking tool and the problem is solved. When you add all these compiler specific attributes and introduce a lot of preprocessor macros I think you are creating a situation where you've created code that is easier to write, but potentially harder to read as there is now a lot more abstraction that a programmer has to wade through (assuming they need to debug that abstraction and not just trust that it just works). Now, if you're using a leak checker you can save that abstraction and switch back to using the standard free(3) library call and then 100% of C programmers will be able to follow the code.

View on HN

Side story: I witnessed a situation in which an embedded board had to be manufactured in a variant supporting a bigger DRAM chip, just so there would be room to run Valgrind on it to solve leak issues!

There is also the problem that valgrind lets you confirm that there are leaks, and pinpoint their source. What it doesn't give you is the root cause of the leak. The cause is distributed! If N places in the program have a pointer to an object, and all those N places obliterate the pointer without freeing the object, then all N places are equally responsible.

Just because you know what is leaking and where it came from doesn't mean that it's obvious how to fix it. Introducing code which tries to free those objects is extremely risky, because if you err on the opposite side of a leak, you have a premature deallocation which destabilizes the program in a different way.

If N places lose a pointer, then it's not necessarily always the same one of those places which is the last one to do so. Yet the last one to lose the pointer must be the one which triggers any manual freeing.

This problem is difficult, which is why we have garbage collection and why the problem is sometimes solved in C programs by sliding in a garbage collector like Boehm.

I guess it's more about writing less & better than using known functions -- in the same reasoning, I /could/ use new/delete in C++, but I always end up using unique_ptr<T>(...) because it's just better, and we usually don't really know/care about the implementation details.

Now I realize that the comparison I made isn't fair since unique_ptr<T> is standard C++ (and hence, polished), and mine isn't and will never be standard C, but abstraction here is not that much of a threat to understanding -- in the end, it's still syntactic sugar on top of smalloc/sfree.

As a last word, I'll say that this is mostly a toy project, and I probably won't have the occasion to fully use it. This is just a proof of concept to say that it is possible to have modern idioms in C.

It would be nice if C++ added syntactic sugar sigils for unique_ptr<T> and shared_ptr<T> like Rust used to.

Good abstractions isolate complexity from the application developer at the expense of the library author. This is true of every abstraction. I find your comment strange. You essentially wrote: just write code that works or is trivially debuggable- true and entirely unhelpful.

Isn't the whole point is to make sure the abstraction always work ?

Isn't the whole point of C to have as minimal abstraction as possible?

Not really, otherwise even the standard library would not exist, and we would manually ask pages to the kernel every time we want memory.

C, as a language, is indeed low level, but that does not mean that programs and libraries shouldn't build abstractions on top of the low level interface.

Not at all. The point of C is to have as much abstraction as possible while still allowing maximal control. And 'as much abstraction as possible' is a matter of historical context, since we learn all the time that there are better ways of doing abstraction than C does.

No it isn't a solved problem, as long C or any other language with manual memory management is used.

It isn't possible to control all the code, specially if a lot of third party libraries or contractors are involved in the project.

As for leak checkers, not all compilers support them (there is more out there than just gcc, clang, msvc, icc), or even when they do, memory constraints might prevent their use.

Reply on news.ycombinator.com