[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[netCDF #QRL-229735]: ndump crashes
- Subject: [netCDF #QRL-229735]: ndump crashes
- Date: Tue, 22 Jan 2013 09:57:28 -0700
> 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