NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi, A user recently requested that NCO support empty record variables. These occur when the record dimension and associated variables have been defined and before any records have been stored. Are such "empty-record" files netcdf conformant? If so, then NCO will try to support them. However, there are some libnetcdf.a issues that arise. First nc_get_var? routines return NC_EINVALCOORDS = Index exceeds dimension bound when called with arguments start=count=0. Is this logical? To me, start and count are exactly zero in the absence of any data. It seems like libnetcdf expects the client program to refrain from calling nc_get_var? functions for record variables with no data, even though doing so could be considered legal. I would appreciate: 1. An explicit statement in the C API guide describing the expected library behavior for files with record variables with zero records, and how calls with start=count=0 will behave. 2. A more appropriate error message (or no error at all) than "Index exceeds dimension bound" for variables that have no data. Does an index of zero exceed the dimension bound when the dimension bound is also zero? I think this case merits a distinct error value/message. Or rather, I think that libnetcdf should return no error, nor data, to a zero element request for a zero element variable. It seems to me that should be legal. More important to me than the behavior in this corner-most case is an explicit statement somewhere on the expected behavior. Thanks much, Charlie -- Charlie Zender, surname@xxxxxxx, Department of Earth System Science 3228 Croul Hall, UC Irvine, Irvine CA 92697-3100. (949) 824-2987 :) ============================================================================== To unsubscribe netcdfgroup, visit: http://www.unidata.ucar.edu/mailing-list-delete-form.html ==============================================================================
netcdfgroup
archives: