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

Re: 980109: netcdf3 interface (bug?)

> 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