Hi.
It is great we can use native functions like stdio.printf, but it seams kind of messy if it has to be invoked platform.posix.printf. In my opinion something like platform.posix.stdio.printf would be much more transparent.
Is there(or will be) available documentation which points for which c header files are generated kotlin bindings? There is plenty of Kotlin bindings for standard header files available, but not every that can be imported from C using #include <> directive, it would be nice if there was a possibility to easly determine for which headers we have to do it ourself.
Note that the content of platform.posix is NOT identical on different platforms, in the same way as different POSIX implementations are a little different.
We’ve gone a little further and provided access to more specific native OS services. One needs to import the proper packages on each of the platform. Choose what matches your target platform:
I was looking something more precisely, something which point what exactly is available on target platform. With platform.posix I can assume it is whole implementation on specific platform but platform.linux, platform.osx, etc. are not so obvious.
Note that the content of platform.posix is NOT identical on different platforms, in the same way as different POSIX implementations are a little different.
I think this refres to the fact, that although osx, linux, windows, etc support the posix standard they may not entirely support all features or have some varying implementations. That being said you could take a look at this wikipedia entry and if you need the specific implementations you could take a look at the kotlin-native github. They define which headers are getting pulled into the different platform packages here.
1 Like
This is perfect, thank you very much. 
Referring to my first paragraph from initial post, is there any reason to not splitting specific C header files between different packages?
I don’t really know. I guess because you need to create a def file per package and having them all in one file is less work. And also there is no conflict between those so there is no technical reason to separate them.
Ok a maybe more valid reason is that in C++ those functions and constants are also not grouped into different namespaces. You need to import them separately but after that they are all part of the same namespace (as far as I know).
If you really want to know the reasoning I suggest you create an issue on github and ask there (and if you do link it, I would be interested as well 
)
As suggested, I created a new issue on Github.
