sentry-native

That may work for your own code which you can pepper with macros, but I needed to be able to capture crashes in native code I didn't write. Android itself has used a variety of unwinders over the years. Extracted versions of the libraries that have been modified to build with the NDK are here: https://github.com/ivanarh/libcorkscrew-ndk https://github.com/ivanarh/libbacktrace-ndk https://github.com/ivanarh/libunwind-ndk https://github.com/ivanarh/libunwindstack-ndk Along with a wrapper that can use all of them: https://github.com/ivanarh/ndcrash It's been a while since I dealt with this and I don't recall why Android keeps changing unwinders. Looks like Sentry is using libunwindstack-ndk (well a fork of it anyway) on Android: https://github.com/getsentry/sentry-native/tree/master/exter...

I disagree; type safety is something that is missing from almost every C api I've used; you end up with opaque handles that are just integers that can be easily misused. Consider the glBufferSubData method [0] - 2 of 4 of those parameters are really just integers that the programmer needs to know about, that the compiler won't check,and the last two are tightly coupled and not type safe; thetes nothing stopping you from passing an array of doubles (or whatever pointer you have lying around). Opengl also gets away with because you're almost always working with either floats or integers (for say index buffers) but once you start dealing with containers of containers, a C api ends up really messy with everything being an "object" and having to call function_str(my_obj_handle) with the correct handle - see sentry's api [1] for an example of

> Put another way, I'd rather fix relatively simple C (which also tends to be simpler code in general) than the monsters created by "modern C++" because they thought the "added safety" would mean they could go crazy with the complexity without adding bugs. It's completely possible to write C++ code without it being a mess of a template mostrosity and massively overloaded function names. People who write C++ like that would write C filled with macros, void pointers and all the other footguns that C encourages you to use instead. I've been working with the sentry-native SDK recently [0] which is a C api. It's full of macros, unclear ownership of pointers (in their callback, _you_ must manually free the random pointer, using the right free method for their type, which isn't type checked), custom functions for working with their types (sentry