[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

970523: netcdf 3.3 with gcc

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.

  • Subject: 970523: netcdf 3.3 with gcc
  • Date: Fri, 23 May 97 14:13:36 -0600
Kate,

>Date: Fri, 23 May 1997 15:03:19 -0400 (EDT) 
>From: Kate Hedstrom <address@hidden>
>Organization: Rutgers University
>To: address@hidden
>Subject: Re: cast problem on FreeBSD 
>Keywords: 199705171514.JAA09636

In the above message, you wrote:

> > I do not think this is really a bug in gcc, but a bug in your
> > program. The real problem is that the value of d is out of range for
> > an integer. A look into K&R2 (paragraph A.6.3) show that the effect of
> > of casting such a value to an integer is *undefined*.  Core dump is
> > thus a perfectly legal behaviour here.
> > 
> ahab% more cast.c
> #include <stdio.h>
> 
> main() {
>     double d = -2147483649.;
>     int i;
>     i = (int)d;
>     printf("%d  %lf\n", i, d);
> }
> ahab% gcc cast.c
> ahab% a.out
> -2147483648  -2147483649.000000
> ahab% cc cast.c
> ahab% a.out
> -2147483648  -2147483649.000000
> 
> All I know is that this particular cast came from a test program for
> the NetCDF package from Unidata.  I haven't had it dump core on any
> other system.  You may well be right, but "make test" is a mess on
> FreeBSD.

It looks like we'll need to investigate your problem a little deeper.

In the first message on this subject, you wrote:

> 7. nf_test.trace
> Note: Line numbers for system and library calls may be incorrect 
> Begin traceback...
> Called from [func: _etext],line 1484 at 0xef6b2c4c, args=0xa 0x2 0xef795a7c 
> 0xef805e78
> Called from [func: ncio_px_get:f(0,1)],line 287 at 0x690d8, args=0xeffff06c 
> 0xe89f4 0xeffff014 0x101308
> Called from [func: getNCvx_schar_double:f(0,1)],line 2694 at 0x774b4, 
> args=0xeffff090 0x1 0xe89f4 0x0
> Called from [func: getNCv_double:f(0,1)],line 4001 at 0x7af68, args=0x100a90 
> 0x1030a8 0xeffff398 0x1
> Called from [func: nc_get_vara_double:F(0,1)],line 6409 at 0x81758, 
> args=0x100a90 0x1030a8 0xeffff398 0x1
> Called from [func: nf_get_vara_double_:F(0,1)],line 86 at 0x5d694, args=0x4 
> 0x1 0xeffff398 0xeffff208
> Called from [func: test_nf_get_vara_double:F14],line 2138 at 0xe760, 
> args=0xe87dc 0xe87b4 0xe8c00 0xe8c0c
> Called from [func: test:F14],line 62 at 0x43d38, args=0xe3800 0xd41e6 0x0 
> 0xef7a0db4
> Called from [func: _MAIN_],line 353 at 0x44790, args=0xd41d4 0xd930 0x12 0x4
> Called from [func: _etext],line 1484 at 0xef740c38, args=0x0 0x1 0x1 
> 0x2e000000
> Called from [func: start],line 0 at 0x2064, args=0x0 0x10 0xeffff894 0xc2000
> End traceback...
> 
> 8. nf_test.out
> ./nf_test
> *** Bus Error = signal 10 code 2 
>  Note: the following IEEE floating-point arithmetic exceptions 
>  occurred and were never cleared; see ieee_flags(3M): 
>  Inexact;  Invalid Operand; 
>  Sun's implementation of IEEE arithmetic is discussed in 
>  the Numerical Computation Guide.
> Traceback has been recorded in file:
>        /d0/kate/netcdf/netcdf-3.3/src/nf_test/./nf_test.trace 

The first traceback entry above is bogus.  Would it be possible for
you to rerun "nf_test" in such a way that the offending code after
ncio_px_get() is revealed?

--------
Steve Emmerson   <address@hidden>