A couple of the `has_XX` variables seem to have values of OFF or ON instead of `empty` or ON which causes incorrect output from the nc-config script since it is using `-z` to test whether the variable is non-empty. This causes nc-config to incorrectly report that the library supports HDF5 or has the version 2 api.
Required PNetCDF version is 1.6.1 or greater; not 1.6.0 as I previously thought.
Note that this is pull request may (partially) satisfy Issue #194 which I just found.
If the netcdf cmake build is configured with explicitly specified hdf5 c and hl libraries:
```
-DHDF5_C_LIBRARY:PATH=${ACCESS}/lib/libhdf5.dylib \
-DHDF5_HL_LIBRARY:PATH=${ACCESS}/lib/libhdf5_hl.dylib \
-DHDF5_INCLUDE_DIR:PATH=${ACCESS}/include \
```
Then it looks like the HDF5_C_LIBRARIES and HDF5_HL_LIBRARIES variables do not get set and then this causes the HDF5 libraries to be omitted from the `TLL_LIBS` symbol in liblib/CMakeLists.txt. This is subsequently used to build `ALL_TLL_LIBS` which is used for `LIBS` which is output as the `Extra libraries: @LIBS@` in libnetcdf.settings.in
The output for `-- Linking against:` is also incorrect as it omits the hdf5 libraries: Output without suggested change:
```
-- Linking against: /usr/lib/libdl.dylib;/usr/lib/libm.dylib;/opt/local/lib/libz.dylib;/opt/local/lib/libcurl.dylib
(later in file)
Extra libraries: -ldl -lm -lz -lcurl
```
versus output with suggested change:
```
-- Linking against: /Users/gdsjaar/src/seacas-parallel/lib/libhdf5_hl.dylib;/Users/gdsjaar/src/seacas-parallel/lib/libhdf5.dylib;/usr/lib/libdl.dylib;/usr/lib/libm.dylib;/opt/local/lib/libz.dylib;/opt/local/lib/libcurl.dylib
(later in file)
Extra libraries: -lhdf5_hl -lhdf5 -ldl -lm -lz -lcurl
```
This also causes a link failure when building libnetcdf.dylib
Re e-eupport VGQ-678069
It was noticed that an attribute value of "nan." was being treated as
legal (it should be "nan"). The reason is that sscanf was not be checked
to see that all the attribute value characters were being read.
Solution is to verify that all characters were being consumed.
Re e-eupport VGQ-678069
It was noticed that an attribute value of "nan." was being treated as
legal (it should be "nan"). The reason is that sscanf was not be checked
to see that all the attribute value characters were being read.
Solution is to verify that all characters were being consumed.
Re e-eupport VGQ-678069
It was noticed that an attribute value of "nan." was being treated as
legal (it should be "nan"). The reason is that sscanf was not be checked
to see that all the attribute value characters were being read.
Solution is to verify that all characters were being consumed.
The count and start arrays are dimensioned to NC_MAX_DIMS even though the maximum size should be NDIMS which is set to 3; possibly, the maximum size could be 2 since only indices 0 and 1 are used to access both start and count. I left it at NDIMS since that matches the number of items in the initialization and is consistent with other uses in the file.
The constant NC_MAX_DIMS is used to dimension the `dimids` arrays which are use to retrieve the dimension ids corresponding to the variables dimensions. By definition, the maximum number of dimension ids is `NC_MAX_VAR_DIMS` as is documented in the `nc_inq_var` documentation:
http://www.unidata.ucar.edu/software/netcdf/netcdf-4/newdocs/netcdf-c/nc_005finq_005fvar.html
dimids Returned vector of *ndimsp dimension IDs corresponding to the variable dimensions. The caller must allocate enough space for a vector of at least *ndimsp integers to be returned. The maximum possible number of dimensions for a variable is given by the predefined constant NC_MAX_VAR_DIMS.
Although the default or standard values of NC_MAX_DIMS and NC_MAX_VAR_DIMS are the same, the correct value to be used here is NC_MAX_VAR_DIMS and not NC_MAX_DIMS. Even though this currently works, it could fail if either NC_MAX_VAR_DIMS or NC_MAX_DIMS is changed and it can also provide an incorrect function usage example that may mislead developers trying to determine the correct usage of the function.
