Accept an options hash passed to Rubinius::FFI::Library#attach_function #3158
+24
−16
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This will make it easier for code targetting the FFI gem to use
Rubinius::FFI
when it is available by allowing keyword arguments to be passed toRubinius::FFI::Library#attach_function
. It will resolve issue #3074. An example of code using options passed toattach_function
is here:https://github.com/chuckremes/ffi-rzmq-core/blob/master/lib/ffi-rzmq-core/libzmq.rb#L62-L69
Currently, this patch accepts an options hash, but ignores all options.
The options used by the FFI gem are listed here, in the implementation:
https://github.com/ffi/ffi/blob/master/lib/ffi/library.rb#L214-L217
The
:blocking
option is a hint to the FFI gem that the C function may block and allows it to prepare MRI to release the GIL. It seems like this option can be safely ignored in Rubinius.The
:calling_convention
option tells the FFI gem what calling convention to use. AFAIK, this is only to support windows API calls, and thus can safely be ignored in Rubinius.The
:enums
and:type_map
options are features that could be added toRubinius::FFI
, but in my opinion should be in a separate, more extensive patch.I also cleaned up a few points of apparent cruft in the function implementation, including reindexing the argument names to make more sense and getting rid of a few assignments that were redundant or assigned to variables that were never used.
I also noticed that a
Pointer
is accepted as thec_name
, so I documented that fact. However, there are currently no specs for this. I'll add some in a separate PR.EDIT: It looks like using a
Pointer
as thec_name
does not actually work, so it was just more cruft. The third commit in the PR now reflects this. If one tries to use aPointer
as thec_name
, one gets the error: