netcdf 2.3.2 now available


Version 2.3.2 of the netCDF package is now available for anonymous FTP:

        file: pub/netcdf.tar.Z

(The above file is actually a link to the true compressed tar(1) file, 
which has the version number encoded in its name.)

This version differs from the previous one (version 2.3.1, which was
released on May 11, 1993) in the following ways:

    * A bug has been found and fixed in the algorithm for generalized
      hyperslab access (thanks to Harvey Davies <hld@xxxxxxxxxxxx>).
      Incorrect results were obtained if the fastest dimension had a stride
      of unity, or if the stride vector was NULL.

    * A bug was found and fixed in ncgen that could occur due to sign
      extension of non-ASCII characters above '\177' (thanks to (Tomas
      Johannesson <tj@xxxxx>).

    * Improvements were incorporated in the MSDOS/OS2 makefiles to work on
      more systems, including those without a coprocessor or the `diff'
      program (thanks to William A. Spencer <lambert@xxxxxxx>).

    * The FORTRAN interface has been ported to DEC's new (64-bit) Alpha 
      platform (this completes the port to that platform);

You should know, however, that the port of the FORTRAN interface to DEC's
64-bit Alpha machine uncovered an ambiguity in the netCDF specification.
In order to allow the writing of portable netCDF code, we have decided,
after considerable discussion, to make a slight change to the netCDF
specification.  This change will not affect the operation or portablility
of existing or future netCDF code that is not intended to run on machines
such as DEC's Alpha.  netCDF code for which such a machine is a possible
platform, however, should be modified or written to adhere to the new

The change is the introduction of a new datatype, which is defined in the
netCDF header file `netcdf.h'.  This new datatype is `nclong'.  Maximally
portable C code should use this datatype to hold all values of type
NC_LONG.  For example:

        #include "netcdf.h"
        int    ncid, lid, status, dimids[NDIM];
        long   start[NDIM], count[NDIM];
        nclong data[SIZE];              /* NB: new datatype */
        lid    = ncvardef(ncid, "somelongvar", NC_LONG, dimids);
        status = ncvarput(ncid, lid, start, count, data);
        status = ncvarget(ncid, lid, start, count, data);

Note that only variables for NC_LONG values should have type `nclong'.
Other, traditionally `long' variables (such as the `count' and `start'
vectors for hyperslab access) should remain as C `long's.

FORTRAN programmers needn't worry about this change because portable
FORTRAN code only has INTEGER values to play with (and not, for example,
INTEGER*4, which is a non-portable datatype).  Thus, no change to the
FORTRAN netCDF interface specification is required.

This is the extent of the change.  The rest of this message gives the
rationale for the change.

The netCDF implementation and interface assume that a C `long' maps
naturally into the 32 bit external integer representation of an NC_LONG.
This is rooted in historical networking code traceable to the BSD functions
ntohl() and htonl().

With the introduction of DEC's Alpha machine, we are seeing reasons to
question this.  The Alpha has 64 bit `long's and 32 bit `int's.  The
natural and efficient choice for a C datatype which maps to an NC_LONG
would, therefore, be `int' rather than `long'.  (We have encountered 64 bit
`long's before on the Cray, but there the `int' is also 64 bits, so there
is no advantage to using different types).

Furthermore, on the Alpha, the FORTRAN INTEGER type is 32 bits; therefore,
keeping the C type as `long' for NC_LONG values would add costly
transformations to the FORTRAN interface on this platform.

On all platforms known to us (with the exception of the Alpha) the typedef
for the new `nclong' datatype is

        typedef long nclong;

and existing netCDF code will run without modification.  On the Alpha,
however, the `nclong' typedef is

        typedef int nclong;

We realize that changes to the interface specification are a hassle.  The
alternative in this case is to burden the Alpha platform (and any future
system which makes similar design decisions) with greater memory usage and
poor FORTRAN performance.

Steve Emmerson,
Glenn Davis,
Russ Rew