If a char valued attribute contains embedded nul characters,
then illegal xml will be generated when using the -x (ncml) flag.
There is not good solution since we have a char value '\0' that
is legal in a netcdf-c char valued attribute, but is completely
illegal in ncml (i.e. xml).
So, implemented hack is to go ahead and generate '�' entities
and then complain that we are generating illegal ncml.
The var struct has a 'dim' field which was not being used
Instead, the dimids field would always search for the dim
with the matching dimid. For db with large numbers of dims,
this could be a significant time sync.
Modified code to always set var-dim[i] when var->dimids[i] was
set (if the dim existed at that point). Then use the var->dim
field instead of var->dimids and search whenever requested.
All var->dim accesses are protected by asserts that verify
non-null and that the var->dim[]->dimid == var->dimids[].
The var struct has a 'dim' field which was not being used
Instead, the dimids field would always search for the dim
with the matching dimid. For db with large numbers of dims,
this could be a significant time sync.
Modified code to always set var-dim[i] when var->dimids[i] was
set (if the dim existed at that point). Then use the var->dim
field instead of var->dimids and search whenever requested.
All var->dim accesses are protected by asserts that verify
non-null and that the var->dim[]->dimid == var->dimids[].
In non-classic netcdf-4 models, it is allowable to have
large numbers of dims and vars. In many operations, the
entire list of dims or vars is searched for a dim/var matching
a specific name which results in *lots* of strncmp or strcmp
calls.
If we add a hash field to the var and dim structs similar to what
has already been done for the netcdf-3 formats, then we can hash the
name being searched for and numerically compare that value with
the var/dim hash value. If they match, then do a more expensive
strncmp call to ensure that the names truly match.
When using static libraries, some systems require that the libraries be ordered in dependency order. Since libhdf5_hl.a depends on symbols from libhdf5.a, it (libhdf5_hl.a) should be listed first. This was discovered and verified on RHEL-6 with gcc-5.2.0.
The HDF5 include directory needs to be updated when explicitly setting the HDF5 libraries and include path. This is done on line 561 when FindPackage finds the hdf5 libraries, but was not being done in the manual setting.
