This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Gottfried, > To: address@hidden > From: Gottfried Necker <address@hidden> > Subject: netcdf problems on a Fujitsu VPP 300 > Organization: . > Keywords: 200002141459.HAA10261 In the above message, you wrote: > I'am trying to compile netcdf 3.4/3.5 on a Fujitsu VPP 300. So far > compilation works fine and most tests (all the C tests) seem to be ok, > with one important exeception: The tests in src/nf_test fail with a > floating point exception: the command nf_test -c aborts with a core > dump. > > After some debugging, I found the reason: the Fortran runtime > environment enables floating point traps. The C enviroment does not! > In nf_test.F the C function ncx_put_int_double (in ncx.c) is called > with an argument of *ip = 2147483648. This is too much for a 32-bit > integer and results in a floating point exception. > Take a look at the code. The error probably occurs in the first line > of the function body. > > int > ncx_put_int_double(void *xp, const double *ip) > { > ix_int xx = (ix_int)(*ip); > put_ix_int(xp, &xx); > if(*ip > X_INT_MAX || *ip < X_INT_MIN) > return NC_ERANGE; > return ENOERR; > } I'm sure that your netCDF library has been built correctly. The problem you've uncovered is due to a portability problem with our Fortran testing routines: there's no portable way, in Fortran, to disable floating-point exceptions. I suggest that you simply install the netCDF libary and use it. > Change the code in ncx.c and maybe some other places. That's probably > the cleanest way, but might have some unwanted side effects. We don't wan't to arbitrarily change the way the user's environment handles floating-point exceptions. Regards, Steve Emmerson <http://www.unidata.ucar.edu>