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

Re: 960405: ncgen 2.4 bug

>From: Dell Long RL3-223 <address@hidden>
>Subject: ncgen 2.4 bug
>Organization: FSL
>Keywords: 199604051739.AA08926

Hi Dell,

> There seems to be a bug in ncgen with one of the more recent changes.
> We use exponential notation for fill values, and the new fill value checking
> in ncgen doesn't allow this.

Currently, whenever you use exponential notation for a constant in CDL, you
are specifying a floating-point constant.  Appending "L" to the end of a
constant that is specified with exponential notation doesn't cause it to be
interpreted as a constant of type "long".  This is the same as in standard
C, where the type of a "1e9L" constant is "long double", not "long" (see
K&R, page 37).  The previous version (2.3.2) behaved the same way with
respect to such constants.

Furthermore, for the _FillValue attribute to work properly, it is required
to be of the same type as the associated variable.  Hence defining a
floating-point _FillValue attribute for a long variable should result in an
error message from the netCDF library.

> >From the "CHANGES" file:
> - ------ Wed 28 February 1996  Changes in netCDF (2.3.2 to 2.4)
> (...)
> Made ncgen generate an error message when the type of the _FillValue
> attribute doesn't match the type of the associated variable.  The library is
> supposed to catch all these, but doesn't for record variables.
> 
> Here's a sample .cdl with the bug:
> 
> - ----- Begin foo.cdl ------
> netcdf foo {
> 
> dimensions:
>     recNum    = unlimited;
> 
> variables:
>     long    foobar(recNum);
>             foobar:long_name = "The following fill value works";
>             foobar:_FillValue  = 1000000000L;
>             foobar:valid_range = 0, 8000;
> 
>     long    barfoo(recNum);
>             barfoo:long_name = "This generates an error";
>             barfoo:_FillValue = 1e9L; 
> }
> - ----- End foo.cdl -----
> 
> This generates the following message:
> ncgen: foo.cdl line 14: variable barfoo: _FillValue type mismatch
> 
> Both of the fill values above work in the 2.3.2 ncgen.

Actually, they only appear to work in the 2.3.2 ncgen, because no error
message is generated until you actually try to use the _FillValue by having
some data.  If you instead add a little data to the above CDL by inserting
the two lines

     data:
           foobar = 1, 2, 3;

before the trailing "}", you will see that the 2.3.2 ncgen also gets an
error, but the message is printed from within the library ncvarput call:

    $ ncgen-2.3.2 -b foo.cdl
    ncvarput: var barfoo: _FillValue type mismatch

The version 2.4 ncgen gives the same message from ncgen instead of ncvarput
and identifies the line on which it occurs:

    $ ncgen-2.4 -b foo.cdl
    ncgen: foo.cdl line 14: variable barfoo: _FillValue type mismatch

The behavior of the 2.3.2 ncgen ignoring this error for record variables
when there was no data was a bug.  Even though it may appear that it allowed
the _FillValue to be specified in this case because it didn't produce an
error message, you can see from the above example that the _FillValue
specified this way would cause problems later, since it was of the wrong
type.

______________________________________________________________________________

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