4 ms·
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()
by zabzonk 9mo ago
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.
- bigfishrunning 9mo ago"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.
- zabzonk 9mo agomy 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.
- Nevermark 9mo agoBoth 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.
- zabzonk 9mo agoThen why not define "something" as static, which makes the compiler and linker guarantee that you can't do it?
- bigfishrunning 9mo agoWhat if I want to internally access it from multiple compilation units, but not necessarily encourage downstream users from using it? This is really common.
- yxhuvud 9mo ago`static inline` is definitely not private. See https://github.com/axboe/liburing/blob/master/src/include/liburing.h#L32 https://github.com/axboe/liburing/blob/master/src/include/li... , for a practical example.
- 1718627440 9mo agoIt'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.
- jlarocco 9mo agoI 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.
- zabzonk 9mo agoi think you replied to the wrong comment
- yxhuvud 9mo agoModern 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.
- Mikhail_Edoshin 9mo agoHere 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.
- 1718627440 9mo agoThen what the FFI needs to target is `int Foo(int a, ...);`. FooVar1 is just a convenience method for the C language binding.
- yxhuvud 9mo agoThat 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.