Thank you, Dana! Do you think it would be appropriate (not just as of the current implementation, but in terms of the interface contract) to use H5free_memory() on the buffer passed into an H5Z plugin, replacing it with a new (post-compression) buffer allocated via H5allocate()?
On Wed, Nov 8, 2017 at 1:23 PM, Dana Robinson <derob...@hdfgroup.org> wrote: > The public H5allocate/resize/free_memory() API calls use the library's > memory allocator to manage memory, if that is what you are looking for. > > > > https://support.hdfgroup.org/HDF5/doc/RM/RM_H5.html > > > > Dana Robinson > > Software Developer > > The HDF Group > > > > From: Hdf-forum <hdf-forum-boun...@lists.hdfgroup.org> on behalf of Jordan > Henderson <jhender...@hdfgroup.org> > Reply-To: HDF List <hdf-forum@lists.hdfgroup.org> > Date: Wednesday, November 8, 2017 at 12:59 > To: "m.k.edwa...@gmail.com" <m.k.edwa...@gmail.com> > Cc: HDF List <hdf-forum@lists.hdfgroup.org> > Subject: Re: [Hdf-forum] Collective IO and filters > > > > Ah yes, I can see what you mean by the difference between the use of these > causing issues between in-tree and out-of-tree plugins. This is particularly > interesting in that it makes sense to allocate the chunk data buffers using > the H5MM_ routines to be compliant with the standards of HDF5 library > development, but causes issues with those plugins which use the raw memory > routines. Conversely, if the chunk buffers were to be allocated using the > raw routines, it would break compatibility with the in-tree filters. Thank > you for bringing this to my attention; I believe I will need to think on > this one, as there are a few different ways of approaching the problem, with > some being more "correct" than others. _______________________________________________ Hdf-forum is for HDF software users discussion. Hdf-forum@lists.hdfgroup.org http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org Twitter: https://twitter.com/hdf5
