FRESH
Hacker News
Hacker News Hacker NewsC++’s shared pointer has the same problem; Rust avoids it by having two types (Rc and Arc) that the developer can select from (and which the compiler will prevent you from using unsafely).
The real problems start when you need to manage memory lifetimes across the whole program, not locally. Can you return `UniquePtr` from a function? Can you store a copy of `SharedPtr` somewhere without accidentally forgetting to increment the refcount? Who is responsible for managing the lifetimes of elements in intrusive linked lists? How do you know whether a method consumes a pointer argument or stores a copy to it somewhere?
I appreciate trying to write safer software, but we've always told people `#define xfree(p) do { free(p); p = NULL; } while (0)` is a bad pattern, and this post really feels like more of the same thing.
C23 didn't introduce it, it's still a GCC extension that needs to be spelled as [[gnu::cleanup()]] https://godbolt.org/z/Gsz9hs7TE
This is cute, but also I'm baffled as to why you would want to use macros to emulate c++. Nothing is stopping you from writing c-like c++ if that's what you like style wise.
Nim is a language that compiles to C. So it is similar in principle to the "safe_c.h". We get power and speed of C, but in a safe and convenient language.
> It's finally, but for C
Nim has `finally` and `defer` statement that runs code at the end of scope, even if you raise.
> memory that automatically cleans itself up
Nim has ARC[1]:
"ARC is fully deterministic - the compiler automatically injects destructors when it deems that some variable is no longer needed. In this sense, it’s similar to C++ with its destructors (RAII)"
> automated reference counting
See above
> a type-safe, auto-growing vector.
Nim has sequences that are dynamically sized, type and bounds safe
> zero-cost, non-owning views
Nim has openarray, that is also "just a pointer and a length", unfortunately it's usage is limited to parameters. But there is also an experimental view types feature[2]
> explicit, type-safe result
Nim has `Option[T]`[3] in standard library
> self-documenting contracts (requires and ensures)
Nim's assert returns message on raise: `assert(foo > 0, "Foo must be positive")`
> safe, bounds-checked operations
Nim has bounds-checking enabled by default (can be disabled)
> The UNLIKELY() macro tells the compiler which branches are cold, adding zero overhead in hot paths.
Nim has likely / unlikely template[4]
------------------------------------------------------------
[1] https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc...
[2] https://nim-lang.org/docs/manual_experimental.html#view-type...
You can do cleanup handling that integrates with your exception handling library by using pairs of macros inspired by the POSIX pthread_cleanup_push stuff.
#define cleanup_push(fn, type, ptr, init) { \
cleanup_node_t node; \
type ptr = init; do cleanup_push_api(&node, fn, ptr) while (0)
#define cleanup_pop(ptr) cleanup_pop_api(ptr) \
}
The cleanup_pop_api call removes the top node, doing a sanity check that the ptr in the node is the same as ptr. It calls fn(ptr).
The fact that cleanup_push leaves an open curly brace closed by cleanup_pop catches some balancing errors at compile time.
The POSIX pthread_cleanup_pop has an extra boolean parameter indicating whether to do the cleanup call or not. That's sometimes useful when the cleanup is only something done in the case of an abort. E.g. suppose tha the "cleanup" routine is rollback_database_transaction. We don't want that in the happy case; in the happy case we call commit_database_transaction.
But if you can stay out of MSVC world, awesome! You can do so much with a few preprocessor blocks in a header
Github has several repositories named cgrep, but the first results are written in other languages than C (Haskell, Python, Typescript, Java, etc).
For the first item on reference counting, batched memory management is a possible alternative that still fits the C style. The use of something like an arena allocator approximates a memory lifetime, which can be a powerful safety tool. When you free the allocator, all pages are freed at once. Not only is this less error prone, but it can decrease performance. There’s no need to allocate and free each reference counted pointer, nor store reference counts, when one can free the entire allocator after argument parsing is done.
This also decreases fallible error handling: The callee doesn’t need to free anything because the allocator is owned by the caller.
Of course, the use of allocators does not make sense in every setting, but for common lifetimes such as: once per frame, the length of a specific algorithm, or even application scope, it’s an awesome tool!
> In cgrep, parsing command-line options the old way is a breeding ground for CVEs and its bestiary. You have to remember to free the memory on every single exit path, difficult for the undisciplined.
No, no, no. Command line options that will exist the entire lifetime of the program are the quintessential case for not ever calling free() on them because it's a waste of time. There is absolutely no reason to spend processor cycles to carefully call free() on a bunch of individual resources when the program is about to exit and the OS will reclaim the entire process memory in one go much faster than your program can. You're creating complexity and making your program slower and there is literally no upside: this isn't a tradeoff, it's a bad practice.
Like, if I was stuck in a C codebase today, [[cleanup]] is great -- I've used this in the past in a C-only shop. But vectors, unique_ptrs, and (awful) shared_ptrs? Just use C++.
// The Old Way (don't do this)
char* include_pattern = NULL;
if (optarg) {
include_pattern = strdup(optarg);
}
// ...200 lines later...
if (some_error) {
if (include_pattern) free(include_pattern); // Did I free it? Did I??
return 1;
// ...200 lines later...
// common return block
out:
free(include_pattern); // free(NULL) allowed since before 1989 ANSI C
return result;Given how simple examples in this blog post are, I ask myself, why don't we already have something like that as a part of the standard instead of a bunch of one-off personal, bug-ridden implementations?
Just don't use C for sending astronauts in space. Simple.
C wasn't designed to be safe, it was designed so you don't have to write in assembly.
Just a quick look through this and it just shows one thing: someone else's walled garden of hell.