[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,

> 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


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.