Does inline do anything here?

To my experience, modern compilers tread inline as white space and just do what makes most sense (e.g. not inlining when emitting a static function into the compilation unit is more compact, or inlinling even without inline if that results in better code).

I personally still tend to add those, as this can be a hint to someone reading the code.

My personal vision is that we just enable LTO by default though, and move all the static inline functions to non-static functions in C files. Not having any C code in the headers makes compatibility with C++ and rust a lot easier and LTO does a better job than static inlines anyway.

Still, but since this is a local callback function it cannot be inlined anyway, right? So having inline as hint might rather confuse people.

Yes, it cannot be inlined when a function ptr is set. Sorry, I missed that detail.

gcc does not treat inline as white space instead "inline" removes the default/implicit extern so without adding another linkage maker the inline marked implementation is only available to be inlined (called in this compilation unit)

inline fn() { } << this can not be pointed to ( as it is no longer linkable) it is also not able to access static variables 

inline static fn() {}  << this can be inlined or staticly linked 

inline extern fn() {}  << this can be inlined or externaly linked

inline fn() {}  << use this implementation is used if inlining 

// another compilation unit may provide 

extern fn() {} << use this implementation is used for extern or to be pointed to 

https://godbolt.org/z/vb7YfKj3v

see compiler warning about no access to static and liker error about not linkable

what this is saying is inline is wrong as this function is not intended be directly called and it is not a good hint but one that leads the reader in the wrong direction

I'd rather have this in a .c file, as I think not inlining this will generate smaller binaries.