a-lafrance / lfc Goto Github PK

In most cases, pointer arguments can't be null pointers; there really aren't enough checks for this right now. This brings up two good ideas:

1. The actual idea, verifying that pointers aren't null
2. Creating a more sophisticated panic system to support this, like a panic_if macro for checking preconditions or something.

For example, use types like uint8_t or int32_t to control the size of a given numeric type, rather than relying on the builtin ones like int which don't have a consistent size platform to platform.

Pretty much what the title says. I have yet to actually build on Linux (or any non-macOS platform) locally, so I have no firm proof that it works. On the other hand, CI refused to work on Linux, so that's not a good sign.

Code is probably memory safe, but I have yet to check with a tool like Valgrind, so I'm not 100% sure about it until I do.

Like, take a linked list for example: say I have a list_t of str_t, all of which must be dynamically allocated for lifetime reasons. When calling ll_free() to free the contents of the linked list, you might try to pass the str_free() destructor so that the contents of each string are freed. The problem with this is that it fails to free the str_t allocations themselves, so you end up with a memory leak because of the constraints of list_t not owning its data.

My best proposal for resolving this is, rather than forbidding non-dynamically allocated data in cases like these, pass some kind of boolean flag around when freeing so that you can specify whether or not the individual data pointers must be freed when freeing the overall data structure. In Rust-like terms, you would be specifying whether or not the data structure owns the data allocations -- if so, the destructor must make those deallocations itself, but if not nothing needs to be done.