NetCDF FORTRAN bug on SGI Irix

• To: netcdfgroup@xxxxxxxxxxxxxxxx
• Subject: NetCDF FORTRAN bug on SGI Irix
• From: neelin@xxxxxxxxxxxxxxxxx (Peter NEELIN)
• Date: Wed, 3 Feb 93 16:20:04 EST

I'm using the NetCDF interface on an SGI 4D35 running irix 4.0.4 and I recently
discovered a problem in reading and writing NC_BYTE variables through the
FORTRAN interface (sorry, NCBYTE variables - I usually use the C interface).
It seems that the fix FORTRAN_HAS_NO_BYTE in the fortran/irix.m4 file has
been set when it should not be, leading my bytes to be interpreted as
integers. The following program demonstrates the problem:

--------------------------------------
      program test
#include <netcdf.inc>
      integer cdf, var, rcode, dim(3), start, count, i
      byte mydat(12), indat(40)
      integer junk(3)
      equivalence (junk, mydat)
      data mydat/1,2,3,4,5,6,7,8,9,10/

      type *, (junk(i), i=1,3)

      start=1
      count=10
      cdf=nccre('test.cdf', NCCLOB, rcode)
      dim(1)=ncddef(cdf, 'xdim', 10, rcode)
      var=ncvdef(cdf, 'var', NCBYTE, 1, dim, rcode)
      call ncendf(cdf, rcode)
      call ncvpt(cdf, var, start, count, mydat, rcode)
      call ncvgt(cdf, var, start, count, indat, rcode)
      call ncclos(cdf, rcode)

      type *, (indat(i), i=1,10)

      stop
      end
--------------------------------------

The output is (the first three values show that bytes are bytes) :
     16909060    84281096   151650304
     0    0    0    4    0    0    0    8    0    0
and ncdump gives :
netcdf test {
dimensions:
        xdim = 10 ;

variables:
        byte var(xdim) ;

data:

 var = 4, 8, 0, 0, 6, 0, 0, 0, 0, 0 ;
}


If I modify jackets.c and remove FORTRAN_HAS_NO_BYTE, I get
     16909060    84281096   151650304
     1    2    3    4    5    6    7    8    9   10
which is correct (ncdump agrees).

The FORTRAN_HAS_NO_BYTE fix is also used in ultrix.m4 and unicos.m4. I know
nothing of unicos, but it would surprise me a great deal if there was no
byte type in ultrix FORTRAN.

If this is truly a bug and I am not mistaken, perhaps it can be incorporated
into the new release.

-- 
            Peter Neelin (neelin@xxxxxxxxxxxxxxxxx)
            Positron Imaging Laboratories,
            Montreal Neurological Institute