Provide high level syntax for dealing with HDF5 files in memory #1077
Conversation
mkitti
commented
Jun 3, 2023
mkitti
commented
- Fix get_driver for Core
- Enhance creating a file from memory using the Core driver
src/api/helpers.jl
Outdated
| buf_ptr_ref = Ref{Ptr{Nothing}}() | ||
| buf_len_ref = Ref{Csize_t}(0) | ||
| h5p_get_file_image(fapl_id, buf_ptr_ref, buf_len_ref) | ||
| unsafe_wrap(Array{UInt8}, Ptr{UInt8}(buf_ptr_ref[]), buf_len_ref[]; own=true) |
There was a problem hiding this comment.
I'm always a little bit worried about own=true: I know the docs say to call free, but I thought that this wasn't correct on Windows?
There was a problem hiding this comment.
It might be safer to do the double call: first call with buf_ptr_ref as C_NULL to get the size of the buffer, then allocate it ourselves, and call it again?
There was a problem hiding this comment.
Oh, i was wrong. You would need to define H5Pset_file_image_callbacks
There was a problem hiding this comment.
What's strange is that HDF5 explicitly provides H5_FREE_MEMORY for this reason elsewhere (see #677).
There was a problem hiding this comment.
We probably should use that. I'll check the HDF5 source later.
There was a problem hiding this comment.
I'm resolving this for now by only allowing the one-arg version with own=true if h5p_get_file_image_callbacks returns a null pointer for image_free.
There was a problem hiding this comment.
Maybe we should still use HDF5.API.h5_free_memory.
