7 ms·

I hate to admit this, but it took me a long time to do, mostly because I was not experienced when I started writing code, and the code has been rewritten severa

I hate to admit this, but it took me a long time to do, mostly because I was not experienced when I started writing code, and the code has been rewritten several times over to get it right. First off is the code in [1]. It's technically under several licenses, but I can give it to you under the public domain because bounds checking in C is important enough that I'll give it away. The `y_ARRAY_TYPE()` macro generates a struct that is an array with bounds. Use it like this: typedef y_ARRAY_TYPE(uint32_t) uint32_t_arr; `uint32_t_arr` is a bounded array of `uint32_t`'s. You can then pass that array to functions and do bounds checks with the `y_i()` macro (for when the struct value is not a pointer) and the `y_ip()` macro (for when the struct value is a pointer). To implement RAII, the code to do that is in the same repo, but it's...much more complicated: a full stack allocator. I just add the destructor as a parameter when allocating memory, and when the allocation is freed, the destructor is called when it's non-NULL. Then there are functions to allocate and free, but it is always done in a stack, to emulate the real stack. By the way, the type of destructor is void (*y_Destructor)(void*) and it takes a pointer to the item to be destroyed. Structured concurrency takes the idea of a thread-local stack and sort of generalizes it across threads. The idea is that each thread has a parent, and that parent is not joined until all of its child threads are joined. All threads form a tree, almost exactly like process trees in Linux. This means that if you want to have another thread borrow an item, you just have to make sure that thread is a descendant of the thread it is borrowing the item from, and you have a guarantee that the item will never go out of scope before the borrowing thread does. Sometimes you need to change your code to do that. You can "push" things "down the stack" by passing function pointer callbacks to callees who then create the item to borrow and call the callbacks. Inside the callbacks, the borrowed item will always exist. There's more to it than that (you can turn a thread tree into a DAG [2], allowing you to turn threads that are not descendants of a thread into descendants), but that's probably good enough to start you off. [1]: https://git.yzena.com/Yzena/Yc/src/commit/cf4c96b3560d/include/yc/array.h https://git.yzena.com/Yzena/Yc/src/commit/cf4c96b3560d/inclu... [2]: https://lobste.rs/s/8msejg/notes_on_structured_concurrency_go#c_wkxbvb https://lobste.rs/s/8msejg/notes_on_structured_concurrency_g...

Ar-Curunir 4y ago
Let's be honest, `y_i(array, 10)` is much less readable than `array[10]`. Sure, you can program with bounds checking, but it's less readable, and less newbie-friendly.
- ghoward 4y ago
  I agree, but you get used to it. With enough familiarity, it's just as readable. The fact that I have built all of this is part of why I don't accept contributions. [1] I don't expect people to be able to read my code. [1]: https://git.yzena.com/Yzena/Yc#open-source-not-open-contribution https://git.yzena.com/Yzena/Yc#open-source-not-open-contribu...
pitaj 4y ago
Okay and what about preventing use-after-free and dereferencing null pointers?
- ghoward 4y ago
  Dereferencing NULL pointers: my code is structured such that every function parameter that can be NULL is marked so. And I check those possibly-NULL pointers. This could also be done with a macro: #define y_d(p) ((p) == NULL ? abort(), *p : *p) Otherwise, the compiler (clang, usually) warns me when a NULL pointer is passed in and I have asserts to catch them. Even before I had all of this infrastructure, deferencing NULL pointers was not a problem for me personally; it's just one of the mistakes I tend to not make. So that's why I don't have a macro for it. For use-after-free, I use scopes. My stack allocator has a function that will mark the start of a scope, and I call it when entering a new scope. Then the pointers that are allocated during that scope will all be freed when I call the function to free every item in the scope, but those pointers will also go out of scope, which means the compiler won't let me access them. It looks like this: void func(size_t s) { y_stackallocator* p = y_strucon_stackallocator(); // Random code. // Open a new scope. Notice that the scope is a bare scope. // But it could also be an if statement or a loop. { size_t* sp = y_stackallocator_malloc(p, sizeof(size_t) * s, NULL); // Random code. // This frees everything in the scope, including sp. y_stackallocator_scopeExit(p); } // Scope has exited; sp is not accessible, no use-after-free. } This is less rigorous than Rust, but I use the principles in Joel's "Making Wrong Code Look Wrong" [1] here. If I have scopes that don't look like the above, they are wrong. [1]: https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/ https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...

Ar-Curunir 4y ago

Let's be honest, `y_i(array, 10)` is much less readable than `array[10]`. Sure, you can program with bounds checking, but it's less readable, and less newbie-friendly.

ghoward 4y ago
I agree, but you get used to it. With enough familiarity, it's just as readable. The fact that I have built all of this is part of why I don't accept contributions. [1] I don't expect people to be able to read my code. [1]: https://git.yzena.com/Yzena/Yc#open-source-not-open-contribution https://git.yzena.com/Yzena/Yc#open-source-not-open-contribu...

pitaj 4y ago

Okay and what about preventing use-after-free and dereferencing null pointers?

ghoward 4y ago
Dereferencing NULL pointers: my code is structured such that every function parameter that can be NULL is marked so. And I check those possibly-NULL pointers. This could also be done with a macro: #define y_d(p) ((p) == NULL ? abort(), *p : *p) Otherwise, the compiler (clang, usually) warns me when a NULL pointer is passed in and I have asserts to catch them. Even before I had all of this infrastructure, deferencing NULL pointers was not a problem for me personally; it's just one of the mistakes I tend to not make. So that's why I don't have a macro for it. For use-after-free, I use scopes. My stack allocator has a function that will mark the start of a scope, and I call it when entering a new scope. Then the pointers that are allocated during that scope will all be freed when I call the function to free every item in the scope, but those pointers will also go out of scope, which means the compiler won't let me access them. It looks like this: void func(size_t s) { y_stackallocator* p = y_strucon_stackallocator(); // Random code. // Open a new scope. Notice that the scope is a bare scope. // But it could also be an if statement or a loop. { size_t* sp = y_stackallocator_malloc(p, sizeof(size_t) * s, NULL); // Random code. // This frees everything in the scope, including sp. y_stackallocator_scopeExit(p); } // Scope has exited; sp is not accessible, no use-after-free. } This is less rigorous than Rust, but I use the principles in Joel's "Making Wrong Code Look Wrong" [1] here. If I have scopes that don't look like the above, they are wrong. [1]: https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/ https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...