Signature for `jl_array_data` is different in stable and nightly

Internals & Design
,
1

Hi, I have some C code with Julia embedding. The code is tested with versions 1.8 and nightly. However, it fails on nightly, due to the changes in the signature of jl_array_data (macro that obtains a C pointer from a Julia Array data structure).

Precisely, as I was able to trace from the GitHub repo, somehow in the current stable release 1.10, there is only macro jl_array_data(a) , but in the master branch (I assume that this branch is used for nightly builds) this macro is renamed to jl_array_data_(a) (mind the ending underscore) and the old name is used for a new macro jl_array_data(a, t) where t is a data type.

Question: How to handle this robustly in the code that I am maintaining? I mean, I still want tests to pass with a stable release and nightly. I understand that the question is more about C than Julia; however due to the lack of experience with Julia, I’d like to ask someone’s opinion about how to handle this API changes in a robust long-term way.

2

I don’t think it’s more complicated than

#ifndef jl_array_data_
#define jl_array_data_ jl_array_data
#endif

and changing your code everywhere to use the underscore-ending macro. But my C is rusty, so I could be off.

Considering that there are no stability guarantees for julia.h, my opinionated recommendation is to use it as little as possible in embedding and do all calls between C and Julia using @cfunction pointers. I.e. handle data in C form in the Julia code rather than handle data in Julia form in the C code.

3 Likes
3

Thank you, @GunnarFarneback! Yes, it seems like the easiest and robust enough.

Regarding handling data, I agree. However, I need to handle data on C side and pass them to Julia.

4

You know your code best but it’s usually possible to pass an element count (or dimensions) and a memory pointer and let the Julia code create the Julia array with unsafe_wrap or via unsafe_load.

1 Like