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

Re: perl interface problem, plus ncdump oddity

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: Re: perl interface problem, plus ncdump oddity
  • Date: Wed, 17 Sep 2003 08:21:58 -0600
>To: address@hidden
>From:  Jason Thaxter <address@hidden>
>Subject: Re: 20030715: perl interface problem, plus ncdump oddity 
>Organization: GoMOOS
>Keywords: 200309161520.h8GFKSLd005087, perl, ncdump, FreBSD gcc

Hi Jason,

> I've found two odd problems with NetCDF tools recently.  I suspect they are
> related to compiler and perl versions, but I don't really know.
> 
> 1) ----------------------------------------------------
> 
> The Perl interface issue involves values retrieved by NetCDF::recget.  The
> variable is a scalar of type BYTE.  Perl always thinks it has a zero (0), even
> though the value (according to ncdump and according to the people who put the
> value there) is a 1 or even a 3.  When I treat the value as a string, I get
> funny control characters - Perl should normally have either an empty string or
> a '0' (zero) depending on the context.  This appears to be related to a
> similar problem I once had - a value that actually was zero cause a coredump
> when I tried operating on it, which I worked around with something like:
>       perl -v -9
> 
> This problem can be observed on netcdf-perl-1.2.2, on
> FreeBSD-4.8+gcc-2.95.4+perl-5.8.0, as well as on
> FreeBSD-5.1+gcc-3.2.2+perl-5.6.1.
> 
> The older problem with zeroes was on netcdf-perl-1.2.1, perl version 5.6.0,
> Redhat Linux 7.1 and 7.2.

If you could provide us with a small example that demonstrates the
problem so we could reproduce it here, we might be able to diagnose
and fix it.

> 2) ----------------------------------------------------
> 
> The second problem I've had is with incorrect values returned by ncdump:
> time for consecutive hours expressed in Julian days is coming out as:
>  time = 2452830.85694444, 14695227408.0627, 775946.000980392,
> with the FreeBSD ports version of netcdf 3.5.0.  Another compile comes out
> with correct versions:
>  time = 2452830.85694444, 2452830.89861111, 2452830.94027778
> 
> The differences are:
> Incorrect: gcc-2.95.4  (compiled under freebsd 4.7, linked to libc.so.4)
> Correct:   gcc-3.2.2   (compiled under freebsd-5.1, linked to libc.so.5)
> 
> Any insight onto these would be a big help.  The issue with the Perl
> interface is more pressing to me, though probably more complicated.

If you built from source, did you run "make test" from the src/
directory after building the library with the package built with
gcc-2.95.4, and did all the tests pass?  If there were no problems
with the "make test", then we would be very interested in a way to
reproduce the problem here.  Again a small test case that allowed us
to reproduce the problem would be ideal.

--Russ

_____________________________________________________________________

Russ Rew                                         UCAR Unidata Program
address@hidden                      http://my.unidata.ucar.edu