This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
> Date: Fri, 9 Jan 1998 13:17:10 -0700 > From: Jim Edwards <address@hidden> > To: address@hidden > cc: address@hidden > Subject: Re: 980109: netcdf3 interface (bug?) Jim, > Thanks for the quick response. I take it that the _uchar and _schar > are not supported in the fortran interface? Oops, this response isn't very quick. You're right, the _uchar and _schar interfaces are not supported in Fortran, because it has no notion of signed and unsigned types. Each language interface supports types native to that language. One implication of this is that data written as unsigned chars in C using the nc_put_var_uchar() interface can only be read as signed chars from Fortran, with nf_get_var_int1(), for example. But all the bits are preserved, so conversion will still be possible. Similarly, if you write out 1-byte ints from the Fortran interface, they will be interpreted as signed for conversion purposes when later read in, either from Fortran or C programs. But again, all the bits are preserved. The fact that Fortran has no unsigned types was actually one of the arguments that swayed us toward interpreting bytes as signed for conversion purposes with netCDF-3. If you were depending on an unsigned interpretation, I'm afraid you'll need to provide a veneer of subroutines that do the desired conversions for you, and indicate the unsignedness of the data somehow with an attribute. With netCDF-4, when we add 32 new packed data types, it should be possible to represent 8-bit unsigned data, just as it will be possible to represent 11-bit unsigned data. --Russ > On Fri, January 9, 1998 at 13:07:09 (-0700), Russ Rew wrote: > > > Date: Fri, 9 Jan 1998 12:59:29 -0700 > > > From: Jim Edwards <address@hidden> > > > To: address@hidden > > > Subject: Re: 980109: netcdf3 interface (bug?) > > > > Hi Jim, > > > > > I have been working for a few months in converting some of our code > > > from the netcdf 2 to the netcdf 3 interface. One of the reasons for > > > doing this is that the solaris compiler (SunOS 5.6 f90: WorkShop > > > Compilers 4.2 ) automatically converts integer*2 and integer*1 to > > > integer in code and so using the netcdf 2 interface will for example > > > cause you to read a short field into half of your array - it doesn't > > > produce an error but it doesn't produce the expected result either. > > > > > > Converting to netcdf 3 and changing our internal types to integer has > > > solved most of the problem. However, I've just run into something > > > that i believe may be a bug in the netcdf 3 interface. > > > > > > A data field is stored as byte in the netcdf file, i read it in as > > > real and get a signed value. I would expect byte to be converted as > > > unsigned, obviously this is open to interpratation, what do you think? > > > > It's not a bug, but it's apparently not documented very well either. In > > the Appendix D, "NetCDF 2 C Transition Guide" of the netCDF User's > > Guide, it says: > > > > 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. > > > > Hence you can use unsigned or signed bytes, but external byte arrays are > > always treated as signed for conversion to other types. This is similar > > to Java, where the byte type is always signed. > > > > --Russ > > > > _____________________________________________________________________ > > > > Russ Rew UCAR Unidata Program > > address@hidden http://www.unidata.ucar.edu