[netCDF #QRL-229735]: ndump crashes

> Hi Russ,
> Thanks for the replies. The problem appears to be that the enumeration
> type has been
> defined with values 1,2,3,4 but no value was actually written to the
> variable.
> By default (I hadn't used  a fill value) a zero appears to have been
> assigned to the variable.
> This is obviously out of range as it neither of the values 1,2,3 or 4.
> I had assumed that enumeration types could handle "undefined" but it
> appears that they cannot. 

Right, there are currently no default fill values for user-defined types.
In most places where the current documentation mentions "default fill values", 
it should be corrected to "default fill values for primitive types".  For a
future update, we may try to define default fill values for the infinite
number of user-defined types by using member-wise or base-type-wise defaults,
but that's not currently implemented and may have issues we haven't considered.

> So to get around this problem I have now extended the
> enumeration types
> with an additional value,  "0", and label it "undefined".
> Is this what you expect the user to do? If so can I suggest that you
> make it explicit in the manual?

Yes, that's a good suggestion.

> Finally, I think that getting this value wrong shouldn't make ncdump
> crash. It makes it very difficult
> to work out what is inside the netCDF file.

I agree.  Ncdump didn't crash in my test, it just reported an "invalid 
argument",
so that may already be fixed in the current snapshot, but we'll add a test for 
it
anyway.  I'll write up a Jira issue for this later this week.

--Russ

> On 01/18/2013 07:35 PM, Unidata netCDF Support wrote:
> > 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
> >
> 
> 

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