There are a number of problems. I pushed an update to the package that deals with some of them:
size_t support was broken after size_t was added as a basic type because some C compilers handle it like that. Only partial support was added though
Handling of types in parameters without using typedef was incomplete.
Handling of explicit signed was broken.
Handling type name as parameter types was broken.
Some of this seems to be used quite rarely … In addition, your Prolog declaration is wrong. The types you specify there are not the C types, but the Prolog facing type. Thus, int should be used for all integral C types. The library finds the actual C type and inserts the correct conversion. You can see why this is necessary as ulong is incorrect for size_t on 64-bit Windows (must be unsigned long long).
The header is now parsed without complaints. Whether it also works cannot be tested without the shared object.
Thanks Jan, my small test is working well. The only thing I noticed is that I can’t do
anymore, but I have to use
It doesn’t matter in this case because long is the same size as longlong but I wonder if this would cause problems in other architectures.
You can download the library here: Download LinAsm from SourceForge.net. Just run make and you’ll get the shared lib. It is a very very fast library, and well done also, as I wrote in another post.
Yes, I did this in the beginning, but then calling c_alloc/2 I used int also, and this of course caused a segfault because int's are 32 bits, so to make it clearer I chose to use longlong in the declaration instead, but I did revert it back to int now.
I see. It does make sense to specify the real type if you need pass an array of some integer type and you do that using the c_alloc/2 predicates. If we do so we should also raise an error if the with of the type from the C header differs from what the user specified. I’m done with ffi for now, but happy to receive PRs.
I think as one option, i.e., -Isomedir/linasm/include
Its long ago. As a general issue with this type of terms that are subject to term expansion, one option is to use a local term_expansion/2 rule that creates the right directive.
The ffi package addresses this by allowing the user to define rules for c_define/2 as you can find in the examples.
Pushed version 0.3. This fixes the longlong issue and works again on MacOS. The MacOS port required supporting function pointer specification without typedef for struct members and function parameters (lacking functionality), ignore some more Clang attributes and type qualifiers and hack around MacOS 11 and later that no longer provide libc.dylib on the filesystem.