frr

Interesting idea with the union and using typeof(). We (I) went with large macros defining wrappers instead, which, I believe, is a necessity with intrusive data structures, or at least I don't immediately see how to do that with unions & typeof. Maybe it's possible...? e.g. hash table wrapper: https://github.com/FRRouting/frr/blob/master/lib/typesafe.h#... (cf. https://docs.frrouting.org/projects/dev-guide/en/latest/list...)

> Is it? Could you elaborate/provide links to examples of this? https://github.com/FRRouting/frr/tree/master/lib/printf Disclaimer: my work. Customised to support %pHX, %pI4, %pFX, etc. - docs at https://docs.frrouting.org/projects/dev-guide/en/latest/logg... for what these do. > What customization would it support? I don't understand your question. It's reasonably readable and understandable source code. You edit the source code. That's the customisation? > Say, compared to these options: https://github.com/eyalroz/printf?tab=readme-ov-file#cmake-o... First, it is customary etiquette to indicate when linking your own code/work. Second, that is not a POSIX compatible printf, it lacks support for '%n$' (which is used primarily for localisation). Arguably can make sense to omit for tiny embedded platforms - but then why is there FP support?

Have they implemented ISO C11 _Thread_local yet? It's been the number one annoyance¹ with porting software to OpenBSD. It is (was?) the only mainline OS without support for native thread-local storage. ¹ e.g. https://github.com/FRRouting/frr/blob/3f290c97e8325bd9db9363...

This is incredibly funny to me, because that's (almost) exactly how some of our other tests work :D (Almost: we have a full-featured command shell and just use that for testing) Shell bindings: https://github.com/FRRouting/frr/blob/master/tests/ospf6d/te... Input: https://github.com/FRRouting/frr/blob/master/tests/ospf6d/te... Expected output: https://github.com/FRRouting/frr/blob/master/tests/ospf6d/te... Absolutely agree this is a great option to have for some kinds of tests.

Here's another example of unit tests for hash tables (and RB-trees and skiplists and…) https://github.com/FRRouting/frr/blob/master/tests/lib/test_... (this file is #include'd from another, with some #define set up:) https://github.com/FRRouting/frr/blob/master/tests/lib/test_... The "tribe" of C developers with distaste for the preprocessor will absolutely hate how this is written. But it works and caught real issues. It doesn't use an external fuzzing tool but rather a deterministic PRNG (see prng_* calls) to get a good mix of call combinations. Coverage analysis was done to make sure it reaches everywhere. (disclaimer: I wrote this. And it did catch bugs. Also it really should have a lot of comments.)

I don't think it's possible to get away with fundamentally no cancellation support, there are enough edge cases that need it even if most applications don't have such edge cases. FWIW, this was also painful to do across threads in our C event loop, but there was no way around the fact that we needed it (cf. https://github.com/FRRouting/frr/blob/56d994aecab08b9462f2c8... )

I agree that the debugging and maintenance experience is much better that way, but it comes at the cost of very poor "DX". We, discussing this here on this thread, understand what's going on. But sadly at least for the projects I'm involved in, the average developer does not. TBH, rather than fancy high-meta generic support, I'd be much more appreciative of ISO C adding something like "_Include" to the preprocessor, e.g. #define DEFINE_MY_WRAPPER(foo, bar) _Include("wrapper.h") /* "foo", "bar" remain accessible in wrapper.h */ I tried implementing this in GCC but didn't get very far, it runs a bit counter to how includes are handled currently. P.S.: I ended up doing this https://github.com/FRRouting/frr/pull/15876/files#diff-90783... instead; a tool that can be invoked to expand some DEFINE_FOO if needed for debugging. It's not us

<300 lines? Peanuts! ;D https://github.com/FRRouting/frr/blob/master/lib/typesafe.h https://docs.frrouting.org/projects/dev-guide/en/latest/list...

https://www.youtube.com/watch?v=8psFQCEgA18 The fact that our CLI client (talking to multiple daemons) can pull and display log messages from the daemons, live, without breaking interactive user input. It's such a simple idea, not quite as simple to implement, but such a massive UX improvement. https://github.com/FRRouting/frr/blob/aa6ceeeb5b1f92280ee797...

https://whatdoesthiscodedo.com/g/5b205f1 > The function adds the specified item to the end of the linked list, while ensuring thread safety using atomic operations. The function first increments the count of items in the list, then uses an atomic exchange operation to add the new item to the end of the list. I'm positively surprised it was able to figure this out, especially after I intentionally removed the comments and changed the function name. That said, this also shows its limits as it completely ignores the atomic memory barriers. Those are the really tricky part that you'd need an explainer for… [source, in case anyone wonders: https://github.com/FRRouting/frr/blob/master/lib/atomlist.c]

Same kind of thing, but typesafe: https://github.com/FRRouting/frr/blob/master/lib/typesafe.h https://github.com/FRRouting/frr/blob/master/doc/developer/l... (disclaimer: it's my work.)

If anyone wants to steal a done-tested-and-working userspace variant (for C, and with limitations C++) of this: https://github.com/FRRouting/frr/pull/6766 It's pretty much the same thing, all occurences of "zlog_debug" and the like create an entry in a separate ELF section. The section can be accessed both at runtime by the program itself as well as offline by reading the appropriate ELF headers (there's an extraction tool in the codebase that does that, it even works cross-OS cross-CPU cross-endian). disclaimer: it's my code ;) disclaimer[2]: this will not work without major overhaul on OSX or Windows. It relies on the binary format being ELF. disclaimer[3]: the PR linked above is only the "core" of it, you may have to fish out other pieces elsewhere.

Typesafe wrapper around the same code: https://github.com/FRRouting/frr/blob/master/lib/typerb.h https://github.com/FRRouting/frr/blob/master/lib/typerb.c Typesafe wrapper with identical API around linked lists, heap & hash: https://github.com/FRRouting/frr/blob/master/lib/typesafe.h https://github.com/FRRouting/frr/blob/master/lib/typesafe.c Docs: http://docs.frrouting.org/projects/dev-guide/en/latest/lists... Typesafe = each tree/list/... uses its own struct and the APIs directly use pointers to the actual member data structures rather than the tree implementation structs. Disclaimer: I wrote these (only the wrapper in case of the RB tree, the entire thing for the others)