This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
I wrote: > It looks like ncdump is reporting that the value it's reading is not a valid > value for the enum type. Specifically, the enum type is defined for values > 1, 2, 3, and 4 using a byte base type, but the actual value read from the > netCDF file > is 0. So ncdump tries to find 0 in the table of symbols for the enum, > doesn't find > it, and reports that with the error return corresponding to "Invalid > argument", as > there isn't a netCDF error code for invalid enum value. > > NC_ERANGE might have been a more appropriate error code to return, but that > ship > has sailed, because changing the error code might break backward > compatibility. > > There may be an error involved in how a 0 was written to the file for a value > of > that enum type. If you have a small example that defines data of that type > and > writes a zero value instead of a valid enum value without returning an error, > that would be a bug we could fix. Thinking about it a little more, it might be more helpful if ncdump printed the invalid value as an integer rather than an enumeration symbol before stopping with an "Invalid argument" error. That would be a clearer indication of the error. I'll see if that's as easy to fix as I think it should be, and check it in to the next release. --Russ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: QRL-229735 Department: Support netCDF Priority: Normal Status: Closed