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
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.