Should nc_free_vlens be called in cases when it doesn't work?

[krisfed]

It is documented that nc_free_vlens() works only when the base type of NC_VLEN is an atomic type (excluding NC_STRING), or an NC_ENUM, or an NC_OPAQUE.

(At least that's how I am interpreting this part of the doc, which is a bit confusingly phrased:

WARNING: this code is incorrect because it will only work if the basetype of the vlen is
atomic
+ enum
+ opaque
excluding string basetype,

The reason is that to operate properly, it needs to recurse when the basetype is a complex object such as another vlen or compound.

)

What is the best practice for situations when nc_free_vlens() is not supposed to work? Should calling it be avoided in the cases when we know it won't quite work?

[edwardhartnett]

I guess so. The result will be some memory leakage.

[DennisHeimbigner]

To address this, I created the necessary recursive function. If
you include the file netcdf_aux.h, you can use the function

int ncaux_reclaim_data(int ncid, int xtype, void* memory, size_t count);

which has the following description:

Reclaim the output tree of data from a call
to e.g. nc_get_vara or the input to e.g. nc_put_vara.
This recursively walks the top-level instances to
reclaim any nested data such as vlen or strings or such.

Assumes it is passed a pointer to count instances of xtype.
Reclaims any nested data.
WARNING: does not reclaim the top-level memory because
we do not know how it was allocated.
Should work for any netcdf format.

[krisfed]

Oh nice, thank you! Is the recommendation then to use ncaux_reclaim_data() instead of nc_free_vlens(), or is ncaux_reclaim_data() still not completely rolled out/tested/included in an official release, and once it is, it might be used by nc_free_vlens() to lift the current limitations? I

[DennisHeimbigner]

The nc_aux_reclaim data subsumes nc_free_vlens, so I would prefer you use it
as it is safer. It has some tests, but it has not been widely used by our users.
I would suggest giving it a try and let me know if you see any problems.
If possible run the code using valgrind or gcc -fsanitize=address to detect
if it is losing memory.

[krisfed]

I think netcdf_aux.h cannot currently be used with a C++ compiler, as it uses "typeid" (C++ keyword) as an argument name:

netcdf_aux.h:44:52: error: expected ')'
EXTERNL int ncaux_end_compound(void* tag, nc_type* typeid);
^

I know this should be fixable by a tiny change of renaming the argument, but any change/patch to netcdf source code means some overhead for us. So it might delay our adoption of ncaux_reclaim_data(), unfortunately. But thank you for the information! We didn't know about the existence of ncaux_reclaim_data(), and it is very good to know that it is recommended over nc_free_vlens() and should overcome its limitations.