here is a little introduction to what I'm currently trying to achieve:
Basically I wrote already a crate which can be used to inspect Blender's binary
.blend files. As documented here it's a library/crate, which can be used from within Rust, but it also ships with a binary standalone program to gather information about such a
.blend file via the command line. The idea is to wrap the Rust crate in a way that the resulting library can be linked against from a C program, because there are many C/C++ developers out there and sometimes there are C/C++ libraries you would like to use (after you extracted information from the Blender file) to e.g. display the resulting scene, or interact with it in real-time etc. ...
In that blog post I described the current status, but the next step is to obviously return bytes to the C caller. In the Rust crate you basically provide a list of names (strings), of (C) structs you are interested in. How such a (C) struct looks like can change between Blender versions, but it's contained within the DNA of the Blender file, how the Blender version, which created that file, did store such information, and the Rust crate/standalone program can be used to query things like that. So my questions start with: How would the C prototype function change (or which signature do you suggest), and how would the Rust counterpart (of the library wrapper) look like? How should I deal with endianness? Should I just return the bytes in the order they are stored? Or should I be aware of the platform I run on and byte swap before I return those bytes?
Thanks in advance