Hi,
It has been proposed that we change the netCDF C interfaces to use long
values rather than ints for netCDF dimensions on all machines. This would
change the interfaces that now use ints or pointers to ints for dimensions:
int ncdimdef(int cdfid, const char* name, int length);
int ncdiminq(int cdfid, int dimid, char* name, int* length);
int ncvarput1(int cdfid, int varid, int *coords, void* value);
int ncvarget1(int cdfid, int varid, int *coords, void* value);
int ncvarput(int cdfid, int varid, int *start, int *count, void* value);
int ncvarget(int cdfid, int varid, int *start, int *count, void* value);
to use longs or pointers to longs instead:
int ncdimdef(int cdfid, const char* name, long length);
int ncdiminq(int cdfid, int dimid, char* name, long* length);
int ncvarput1(int cdfid, int varid, long *coords, void* value);
int ncvarget1(int cdfid, int varid, long *coords, void* value);
int ncvarput(int cdfid, int varid, long *start, long *count, void* value);
int ncvarget(int cdfid, int varid, long *start, long *count, void* value);
The proposal involves no change to data representation or file formats,
since the XDR form of integers is already 32 bits. One advantage of this
change is that on platforms such as MSDOS machines on which integers are
only 16 bits, it would be possible to access data from variables that have a
dimension greater than 32767. This turns out to be of some practical
importance, since CD-ROM disks are being written with large datasets in
netCDF form, and it would be desirable to be able to access this data from
inexpensive 16-bit machines.
Since ints and longs are the same on almost all current platforms (Suns,
DECstations, VAXen, IBM RS6000s, SGIs, HPs, CRAYs, ...), this change would
not break old code. Applications compiled with the old interface on such
machines would work the same way as they did before without recompiling.
Standard C compilers that support prototypes would permit using int values
for dimension size and would automatically convert them to longs before the
call. C code that used pointers to ints instead of pointers to longs (where
required by the new interfaces) would elicit warning messages from lint and
from standard C compilers, so all such problems would be caught at compile
time.
The main disadvantage of this proposal is that programs compiled under the
old interface on machines with 16-bit ints (primarily MSDOS machines based
on the 80286 or earlier chips) would have to be recompiled. But such
programs are also the main beneficiaries of the proposal.
An alternative proposal with a bit more backward compatibility would keep
all the old interfaces and provide six new function names for the new
interfaces that use longs instead of ints. The disadvantages of this are
that the original names were perfect :-), that the new names would further
pollute the already crowded global name space, and that programs written
using the old interface would have to be edited for 16-bit machines.
No change is proposed for the Fortran interface, since MSDOS Fortran
compilers provide an option to treat INTEGER as a 32-bit type.
If you have any comments about the proposed change or feel strongly about it
one way or the other, please let us know. Thanks!
--Russ
"I've finally learned what `upward compatible' means. It means we
get to keep all our old mistakes."
[Dennie van Tassel]
