[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #FMK-929748]: checking NC_ERANGE for type conversion from schar to uchar

Wei-keng,

> The document seems to mention only char cases, but not int/uint or other 
> types.

I only quoted the paragraph about byte types, but the section on
type conversion deals with other types as well, though it doesn't
discuss signed/unsigned issues with other integer types.

> I wonder if the same principle applies to other data types.

No, there was a special case for byte types, because earlier versions
of netCDF said in the documentation that whether bytes were signed or
unsigned was "platform dependent".  That meant we had to be careful not
to invalidate programs that assumed bytes were signed or unsigned.

Hence the intentional lack of support for conversion to signed or 
unsigned bytes, but to instead just copy the bits when reading or
writing data from an array of bytes on disk to an array of bytes
in memory, or vice-versa.

> Here is what I just tried to test int/uint. I added a line below after line 
> 337
> err = nc_get_att_uint(ncid, NC_GLOBAL, ATT_INT_NAME, uint_in);
> and check the returned error code, err. I found when the file is
> created in the classic format, the err is NC_EBADTYPE. When the file
> is created in netCDF-4 format, the err is NC_ERANGE.
>
> In file libsrc/attr.m4, it appears that function NC3_get_att() does not
> allow a type conversion from int (file) to uint (memory). Hence NC_EBADTYPE.
> 
> NC_ERANGE from nc4 implies this conversion is allowed but just failed the 
> range check.

Hmmm, you may be right, it looks like there was some confusion about 
type conversion in these tests and in the library. I don't think it 
should depend on the file type, and the behavior for the netCDF-4 file
seems correct. Thanks for reporting the problem. 

When I verify how extensive the problem is, I'll create a Jira issue.

--Russ

> On Oct 6, 2014, at 1:53 PM, Unidata netCDF Support wrote:
> 
> > Wei,
> >
> >> I notice a comment at line 336 in file nc_test/tst_atts3.c.
> >>
> >> 336      /* Shouldn't this get an NC_ERANGE error for storing -128 into an 
> >> unsigned char?  Possible bug ... */
> >> 337      if (nc_get_att_uchar(ncid, NC_GLOBAL, ATT_SCHAR_NAME, uchar_in)) 
> >> ERR;
> >>
> >> The test runs without errors on this line. But shouldn't it return 
> >> NC_ERANGE?
> >>
> >> nc_get_att_uchar() traces down to ncx_getn_schar_uchar() in file 
> >> libsrc/ncx.c
> >> at line 2201. I can see the function does not check for negative values in 
> >> *xpp,
> >> a signed char, which should cause the out of range error for an unsigned 
> >> char type.
> >>
> >> Is this supposed to be a correct behavior?
> >>
> >> (I can see the same for ncx_getn_int_uint() when X_SIZEOF_INT == 
> >> SIZEOF_INT)
> >
> > Here's some relevant documentation that used to be included in the
> > netCDF-3 C Users Guide in an appendix on type conversion in netCDF-3,
> > and is also in the type conversion section of the current release
> > candidate:
> >
> >  http://www.unidata.ucar.edu/netcdf/docs_rc/data_type.html#type_conversion
> >
> >  ... The _uchar and _schar functions were introduced in netCDF-3 to
> >  eliminate an ambiguity, and support both signed and unsigned byte
> >  data. In netCDF-2, whether the external NC_BYTE type represented
> >  signed or unsigned values was left up to the user. In netcdf-3, we
> >  treat NC_BYTE as signed for the purposes of conversion to short,
> >  int, long, float, or double. (Of course, no conversion takes place
> >  when the internal type is signed char.) In the _uchar functions, we
> >  treat NC_BYTE as if it were unsigned. Thus, no NC_ERANGE error can
> >  occur converting between NC_BYTE and unsigned char.
> >
> > So I think the code is behaving as the last sentence in this
> > documentation says was intended. I seem to recall that there
> > were backward compatibility issues with programs that were
> > converted from the old netCDF-2 API if we didn't just copy
> > the bits between unsigned bytes and signed bytes, rather than
> > checking for conversion errors ...
> >
> > --Russ
> >
> > Russ Rew                                         UCAR Unidata Program
> > address@hidden                      http://www.unidata.ucar.edu
> >
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: FMK-929748
> > Department: Support netCDF
> > Priority: Normal
> > Status: Closed
> >
> 
> 

Russ Rew                                         UCAR Unidata Program
address@hidden                      http://www.unidata.ucar.edu



Ticket Details
===================
Ticket ID: FMK-929748
Department: Support netCDF
Priority: Normal
Status: Closed