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
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.