Re: More help

> To: address@hidden
> Subject: More help 
> Date: Mon, 04 Nov 96 13:00:03 -0500
> From: address@hidden

Chris,

> Thank you very much for your quick response.  Sorry about keeping you in the 
> dark about the version -- it is 2.4.3.  From what I interpret, it sounds like 
> netCDF will interpret a variable declared "unsigned char" as unsigned.  But 
> it 
> doesn't seem like that is happening for me.  It appears that netCDF is 
> interpreting it as a "signed char".  Perhaps I am overlooking something.  
> Here's 
> the relevent code I use to read in the data and send to the netCDF file :
> 
> /*  Variable Declarations  */
> int ncid;
> int reflect_id;
> int reflect_dimids[2];                /*  Variable shape      */
> unsigned char ref[4000][256];
> int htid;                     /*  Dimension 'ht' ID   */
> int timeid;                   /*  Dimension 'time' ID */
> static long startref[] = {0, 0};         /*  Start of reflect values */
> static long countref[] = {4000, 256};    /*  End of reflect values   */
> 
> 
> main () {
> 
> /*  Define variable  */
> reflect_dimids[0] = timeid;
> reflect_dimids[1] = htid;
> reflect_id = ncvardef(ncid, "reflect", NC_BYTE, 2, reflect_dimids);
> 
> /*  Open data file to read binary  */
> infile = fopen("0522a003.dat", "rb");
> while (!feof(infile))  {
>    fread(ref[t], 256, 1, infile);
> }
> 
> /*  Write data to netCDF file  */
> ncvarput(ncid, reflect_id, startref, countref, ref );
> 
> }

Sorry, but I don't see any evidence that the ref variable is being
interpreted as signed.  The code you have supplied shows using an
ncvarput() call to write the unsigned chars to a netCDF file.  It will
write each 8-bit byte of ref as an 8-bit byte, doing no arithmetic on
it, so the external representation on the disk need not be interpreted
as either signed or unsigned.  In fact, netCDF doesn't have separate
signed and unsigned types or representations for signed and unsigned
bytes, it just treats them as bland 8-bit bytes.

When you read the data in later with an ncvarget() call, presumably you
read it into an unsigned char variable.  In that case, it will be
unsigned, and should exactly agree with what you wrote out.

Just guessing here, but by any chance are you assuming the data in the
file is signed because you run "ncdump" on it and "ncdump" outputs the
data as signed?  The way ncdump outputs byte data is platform dependent.
On platforms where in C a "char" value is signed, it will output the
data as signed (e.g. a Sun SPARCstation); on platforms where by default
a "char" is unsigned, ncdump will output byte data as unsigned (e.g. an
SGI).  This is because ncdump just prints the values using a "%d" printf
format, and C doesn't specify whether the default for "char" values is
signed or unsigned.  Hence "ncdump" will print the same byte data as
signed or unsigned when run on different platforms.  But the data on the
disk is neutral, and can be interpreted either way.

This doesn't cause problems with "ncgen", because it still recovers the
same 8-bits of each byte, no matter how it is represented as a print
string.

This definitely needs better documentation.  I just looked in the NetCDF
User's Guide description of "ncdump" and could find no mention of this
"feature".  However it does say (p. 21):

    It is currently possible to interpret byte data as either signed
    (-128 to 127) or unsigned (0 to 255).  The current version of the
    netCDF library simply reads and writes 8-bit bytes without needing
    to know whether they are signed. ...

I'm working on the netCDF-3 User's Guide now, and will make sure this
behavior of "ncdump" is better documented.

--Russ

_____________________________________________________________________

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