nc_inq_dimids and nc_inq_varids

[DennisHeimbigner]

I just noticed that the function nc_inq_dimids and nc_inq_varids
are only allowed if netcdf-4 is enabled. But they are implemented
in non-netcdf-4 dispatch tables (e.g. netcdf-3, pnetcdf).
This means that if you build with netcdf4 disabled, then you cannot
call those functions for an e.g. netcdf-3 file. Instead, one has to
get the # of dimensions (using nc_inq()) and then iterate from 0..ndims-1.
This seems kind of odd to me since it forces a requirement on the netcdf
library that the dimension ids cover the range 0..ndims with no gaps.
Should we consider making nc_inq_dimids and nc_inq_varids be independent
of netcdf-4? This will require a straightforward change to the dispatch table
layout.

[edhartnett]

Yes, excellent idea.

[czender]

While I favor exposing those functions to the netCDF3 API, I request careful consideration and advance warning before relaxing the undocumented, internal requirement that dimension IDs be sequential with no gaps starting from 0, i.e., please don't do that without a compelling reason.

[edhartnett]

The requirement that IDs start at 0 and proceed through num_items - 1 is deeply embedded into the netCDF API. It can not be changed. Many, many, many user programs would break.

I believe that nc_inq_dimids and nc_inq_varids should work for netCDF-3 files, but I don't believe that the numbering of anything can be changed. That's how I was reading Dennis' idea above.

In this case, nc_inq_varids() and nc_inq_dimids() are pretty boring, as they will just give the numbers from 0 to nvars - 1 or ndims - 1. But that's fine. It will allow these functions to work for all types of files, and that will make it easier for the user to use them without worrying about whether classic files will be involved.