Remove unsafe @cfunction wrappers CVRhsFn_wrapper and similar #384
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.
Addresses issue #381
This is theoretically a breaking change, however any application code that was using the low-level API in this way (passing a Julia function into eg CVodeInit and relying on CVRhsFn_wrapper) would likely segfault randomly due to garbage collection of the wrapper.
The problem with CVRhsFn_wrapper and similar is that a temporary Base.CFunction closure is returned by @cfunction($f, ...), which may be garbage collected hence it is not safe to return the enclosed pointer.
This is somewhat similar to the problem with NVector addressed by PR #380, but more fundamental as the RHS function needs to persist for the whole lifetime of the solver use.
Fix here is to remove these wrappers (which were only used by a few tests of the low-level interface), and require that the caller either uses the @cfunction(f, ...) form to generate a C pointer (ie f known at compile time and the runtime Julia RHS function passed in to Sundials C code as part of the opaque user data, this is what the high-level interface does), or manages the lifetime of the @cfunction explicitly.