Add a new function called nc_inq_format_extended that
returns more detailed format information (vis-a-vis
nc_inq_format) about an open dataset.
Note that the netcdf API will present the file as if it had
the format specified by nc_inq_format. The true file
format, however, may not even be a netcdf file; it might be
DAP, HDF4, or PNETCDF, for example. This function returns
that true file type. It also returns the effective mode for
the file.
signature: nc_inq_format_extended(int ncid, int* formatp, int* modep)
where
* ncid is the NetCDF ID from a previous call to nc_open() or
nc_create().
* formatp is a pointer to a location for returned true format.
* modep is a pointer to a location for returned mode flags.
Refer to the actual list in the file netcdf.h to see the
currently defined set.
Also added test cases (tst_formatx*).
the rest of the dimension queries. Correct error in library where types used
in sub-group variables but that were added to the file after the sub-group was
created weren't available for sub-group variables to use. Start cleaning up
test suite and un-commenting tests that were commented out (got up to
nc_test4/tst_fills2.c, alphabetically) before running into an error in HDF5.
Columbia server does not serve up proper
opendap DDS replies. The Dataset {...} name
changes depending on if the request has certain
kinds of constraints.
Code for a hack was not being used, so restore it.
The fix is to effectively ignore differences in
Dataset node names if the code is coming from
columbia.edu.
2. [NCF-278]
The ncgen code is improperly typing int64 integer constants
as uint64.
3. [NCF-279]
Empty string constants were not being properly
filled when their target array is length 1 or more.
Fix bug introduced by [NCF-267].
The bug was that octal constants that had
the highest bit set (e.g. '\200')
were not recognized as proper octal
constants. Fix was to keep as integer
until it was needed as an 8-bit byte.
Ncgen is unable to resolve
ambiguous references to an enum
constant when two different enums
have same econstant name.
Solved by allowing more specific
forms for econstant references.
1. /.../enumname.enumconstname
2. enumname.enumconstname
3. enumconstname
Case 1 is resolved by using the econstant
in the specific enum definition. If none is
found, an error is reported.
Case 2 is resolved by
1. finding an enclosing group with an
enum definition with the specified name
and containing the specified econstant.
If there are more than one, then an error is reported
2. finding all enum definitions in the dataset that have
the specified enum name and contain the specified
econstant. If more than one is found, then an error is reported.
If the above two methods fail, then report an error.
Case 3 is similar to case 2, but all enums, irrespective
of name are used if they contains the specified enum constant.
The ref_tst_econst.cdl test in ncdump is causing ncdump
to fail. So there may be yet some problem.
Added information about needing to generate configure scripts with 'autoreconf'.
Updated Building with CMake documentation, moved 4.3.0 errata to a place of less prominence.
transition document.
Remoted plain text release_notes moving forward. Created a markdown
version of the README file as an experiment to see what we think.
GitHub will render markdown natively, as does Doxygen and our new
build system.
-DENABLE_DYNAMIC_LOADING to cmake-based builds.
This will allow for compatibility with hdf5 1.8.11 builds that
have enabled dynamic building (depends on libdl).
See Jira ticket NCF-258
