Hi,
rsignell@xxxxxxxxxxxxxxxxxx (Richard P. Signell) writes:
> We have discovered that on a 16 bit MS-DOS machine we
> cannot access data beyond the 32,768th element in any
> given dimension. This is because the netcdf routine
> ncvarget, the corners are declared as "int", which on
> a 16 bit machine, are 16 bits.
>
> It appears that what is needed is to write a new routine
> for 16 bit platforms called ncvargetl (or something) that
> uses long integers instead of ints. Has anybody confronted
> this problem?
>
> We cannot simply use a 32-bit 386 machine, because we are
> creating a CD-ROM that neads to work on campuses and high
> schools around the country. From my inquiries, it seems that
> no compiler for 16 bit machines has the option of intepreting
> ints as longs.
Glenn Davis has developed and we are having Rich Signell test a workaround
for this problem, that changes the type of dimension values and index values
from "int" to "long" on MSDOS platforms. Note that this also changes the
interfaces to the library functions ncdimdef(), ncdiminq(), ncvarget1(),
ncvarget(), ncvarput1(), and ncvarput(), which would use "longs" instead of
"ints" for dimensions and index values and pointers to longs instead of
pointers to ints for arrays of dimension values, indices, and edge-lengths.
In the next release, it looks like we will have to change the documentation
and interfaces slightly to specify the use of an abstract type for
dimensions that will be defined via a typedef in netcdf.h, so that the type
of dimensions will be appropriate for the platform on which the library is
compiled. This will preserve the portability of both data and programs that
use netCDF, so that programs on small platforms on which ints are only 16
bits can access any part of large arrays of netCDF data written on platforms
where ints are more than 16 bits.
Programs that follow the current interfaces and declare dimensions as "int"s
will still work on platforms they work on now, but will have to use the new
"nc_dim" type for declaring dimensions if they are to also work correctly on
MSDOS platforms with 16-bit ints where the dimensions of data accessed may
exceed the capacity of 16-bit ints.
Thanks to Rich Signell for bringing this problem to our attention. Rich
Lysakowski has pointed out a similar problem with the ncdump utility that
will also be fixed in the next release.
--Russ
