> I really wish someone on the C language/compiler/linker level took a real look at the problem and actually tried to solve it in a way that isn't a pain to deal with for people that integrate with the code.

It exists as "inline" and "extern inline".[1] Few people make use of them, though, partly because the semantics standardized by C99 were the complete opposite of the GCC extensions at the time, so for years people were warned to avoid them; and partly because linkage matters are a kind of black magic people avoid whenever possible--"static inline" neatly avoids needing to think about it.

[1] See C23 6.7.5 at https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf#p...

> "static inline" neatly avoids needing to think about it.

Sure, except when you do FFI bindings. Then those functions just don't exist and you get a linking error.

Compile using `-fkeep-inline-functions`.

Doesn't help. The point is to avoid having to invoke a C compiler when working in X language. But it would certainly be nice if the distros enabled that.

If it's not in the .h file it's supposed to be a private function.

What makes you think functions defined as `static inline` is not in the .h? These are very much not private functions.

Example: https://github.com/axboe/liburing/blob/master/src/include/li...

you can access it using extern from anywhere:

    // a.c
    int f( int x ) {
        return x + 1;
    }

    // b.c
    extern int f(int x );

    int main() {
        int y = f(41);
    }

but if f() had been defined as static, you couldn't do this.

"private function" doesn't mean "you can't know about this", it means "you shouldn't rely on this as a stable interface to my code".

Just because you can use the information you have to call a given function, doesn't mean you aren't violating an interface.

my point was that f() had been defined static then you can't access it from outside the translation unit it is defined in - in other words, it is "private". i'm afraid i'm unclear what your point is.

`static inline` is definitely not private. See https://github.com/axboe/liburing/blob/master/src/include/li... , for a practical example.

It's going to become private, but its part of your side of the interface, not of the other side. The ABI boundary is between that `static inline` function and the library, not between that function and your code.

Both points are related and matter.

For most purposes, not being able to access something, and being able to access something not officially in an interface, where doing so introduces an unpredictable breaking dependency, the practical result is the same: You can't (actually/sensibly) do it.

Then why not define "something" as static, which makes the compiler and linker guarantee that you can't do it?

What if I want to internally access it from multiple compilation units, but not necessarily encourage downstream users from using it? This is really common.

I don't see what you're getting at with respect to writing bindings.

The whole point of using "static" in that way is to prevent people from using it outside of the file.

If you need to call a static function (inline or otherwise) from outside of the compilation unit to use the API, then it's a bug in the API, not a problem with static.

I agree with you about pre-processor macros, though.

Here is a use case. I have a function that takes variable parameters, so there is no formal type control:

    int Foo(int a, ...);

But in fact the types are restricted depending on a call type, set by 'a'. So I could add a wrapper for a specific variant:

    static inline FooVar1(char b, long c)
    {
        return Foo(FOO_VAR_1, b, c);
    }

All the wrapper does is adds a bit of type control during compilation, otherwise it must be just a function call to 'Foo'. It is like a supermacro. It does make sense to put that into 'static inline' in a header.

Then what the FFI needs to target is `int Foo(int a, ...);`. FooVar1 is just a convenience method for the C language binding.

That is not an option - it may be layers on layers of them and force you to recreate half the library and force you to have to redo subsequent version updates in your code. Then a shim is the preferred solution. But anything that requires a C compiler for FFI is something that won't make anyone happy. Hence my claim that it really is something that needs fixing on the language or linker level.

But FooVar1 isn't part of the library, that's the point. Sure, the library developer could choose to make it a part, but he explicitly choose to not make it a part of the library. Hence, it is also nothing that needs fixing, because it is already possible to make the interface boundary somewhere else, people just choose to do it this way. As far as the language and the linker is concerned FooVar1 is part of your code, not part of the library.

If the language provides nice features to libraries for C language users by sabotaging the library for use outside the language, then this is absolutely a problem on the language side.

The library interface says to do X call `Foo(FOO_VAR_1, b, c)`. That is what you need to somehow call from another language using FFI. In addition it also has an example wrapper for convenience. You can choose to also include that example as part of your implementation in another language, but you don't need to. I fail to see how that is sabotaging.

It also does not have to do anything with the language, because it IS possible to have FooVar1 as part of the interface. The library developer just didn't want that, likely because they do not want tons of slightly different functions in the interface that they would need to maintain, when they already exposed that functionality.

EDIT:

Concerning your earlier complaint, that you would need to

> have to redo subsequent version updates in your code.

, such a change would be ABI-incompatible anyway and demand a change in the major version number of the library. Neither your FFI, nor any program even when written in C, is going to work anymore. The latter, would just randomly crash, not sure about the former.

Note, that you also see here, where the real interface is. A change to Foo itself, would break programs written in C as well as your FFI, while a change to FooVar1 wouldn't matter at all. Both C programs and your FFI will continue to run just fine without any changes.

> likely because they do not want tons of slightly different functions

No. They do it because it avoids the overhead of dynamic dispatch. Nothing else.

So when I've seen these in reality in real library interfaces they have not been 'example wrappers'. They are real intended usage of the API, and in some cases the lib authors recognize that it is a problem and even provide ways to build it without the issues - either by compile time flag or always outputting two variants of the .so. The former moves the question to the distro - should they provide the version optimized for C or the one optimized for other languages? In the case of the latter it obviously creates a situation where the vast majority of both .so-s are duplicated.

As an example of the compile flag, there is libpipewire. As an example of providing two versions of the .so, there is liburing.

So no, this is clearly something the language ecosystem lacks a good answer to. There is currently no way to make everyone happy.

> such a change would be ABI-incompatible anyway

True, but the C based ones can at least simply rebuild and the problem would go away.

Modern libraries consistently use `static inline`, to avoid the overhead of dynamic dispatch. Just take a look at liburing, and the client libraries for pipewire and wayland. All of them have `static inline` all over the place, for methods that are definitely intended to be called.

i think you replied to the wrong comment