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

[netCDF #AFY-830195]: Possible bug in ncdump

Maksym,

> I would also appreciate if you can come up with a workaround that would
> not involve installing a new version of the NetCDF library, if possible at
> all.

The bug is fixed in the current snapshot available from GitHub and so will be
in the next release.

If you are building an application that uses the netCDF library and don't want
to require that your users build and install a new release, you could link your
application statically to a locally updated netCDF library, and distribute the
statically linked binaries for platforms that you have available. However, 
that's
a difficult and maintenance-heavy way to support and deploy software.

The essence of the fix was very simple, increasing one integer value from 20
to 100, so it would be possible though bad practice to edit the binary of either
the library or an application statically linked to a non-updated library to 
accomplish the fix, but I can't recommend doing that to avoid rebuilding from
source.  However, if you want to follow that course, the essential change was
the first one-liner in the source for ncdump/ncdump.c changing "20" to a macro
that has the value 100 in this patch

  
https://github.com/Unidata/netcdf-c/commit/3d5be0b3f058d0a79fe813f11567ed05b3c7ed88

The only justification I can see for such binary editing is if you are trying 
to fix
code in an embedded device, such as on a spacecraft, but I notice you work 
for or with NASA Goddard, so you might be a rocket scientist :-) .

--Russ

> On 7/30/15, 3:29 PM, "Unidata netCDF Support"
> <address@hidden> wrote:
> 
> >Hi Maksym,
> >
> >> I have not found a proper web page to report a bug, so here it goes in
> >>the
> >> email.
> >
> >Thanks, this is an excellent place to submit a bug report. I've added it
> >to
> >our bugrtracking system, so you can see progress on fixing it here:
> >
> >     https://bugtracking.unidata.ucar.edu/browse/NCF-339
> >
> >> In the attached file, there is a Œstats¹ variable that has an attribute
> >> called Œm¹. It¹s value is 7.027888266497819E-9 (note the E-9 part) .
> >> When I do
> >>
> >> ncdump 1.nc
> >>
> >> I get stats:m = 7.02788826649782e-09 ;
> >>
> >> ncdump ­x 1.nc
> >>
> >> Gives me <attribute name="m" type="double" value="7.02788826649782e-0"
> >>/>
> >>
> >> In other words, xml output looses exponent part of this float number.
> >
> >Yikes, that's pretty serious.  Thanks for the bug report. I'll try to fix
> >that soon
> >enough to get in the upcoming 4.4.0 release.
> >
> >--Russ
> >
> >Russ Rew                                         UCAR Unidata Program
> >address@hidden                      http://www.unidata.ucar.edu
> >
> >
> >
> >Ticket Details
> >===================
> >Ticket ID: AFY-830195
> >Department: Support netCDF
> >Priority: Normal
> >Status: Closed
> >
> 
> 
Russ Rew                                         UCAR Unidata Program
address@hidden                      http://www.unidata.ucar.edu



Ticket Details
===================
Ticket ID: AFY-830195
Department: Support netCDF
Priority: Normal
Status: Closed