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

960926: netCDF bug: storing double in long attribute on Cray

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: 960926: netCDF bug: storing double in long attribute on Cray
  • Date: Thu, 26 Sep 96 16:27:01 -0600
Hi Harvey!

> To: address@hidden
> cc: DIX Martin <address@hidden>
> From: Harvey DAVIES <address@hidden>
> Subject: netCDF bug report
> Organization: CSIRO
> Keywords: 199609260406.AA01035

> Using netCDF 2.4.3 on Cray Y-MP4E/464 running UNICOS 8.0.4 I get following
> problem (which does not occur on SGI system).  I have not tried netCDF 3.
> 
> It seems that ncattput (which changes type from long to double) overwrites
> variable.  Here is a program which illustrates the bug:
>
> $ cat t.c
> #include "netcdf.h"
> 
> int
> main() {
> 
>    int  ncid;                   /* netCDF id */
>    int  year_id;                  /* variable id */
>    double  av = 6;    /* attribute value */
> 
>    ncid = ncopen("m.nc", NC_WRITE);
>    year_id = ncvarid(ncid, "year");
>    ncattput (ncid, year_id, "valid_min", NC_DOUBLE, 1, (void *) &av);
>    ncclose (ncid);
>    return 0;
> }
> 
> This following runs the program with before & after ncdumps.
> Note how the value of year changes from 9 to 92.
> 
> $ ncdump m.nc
> netcdf m {
> variables:
>         long year ;
>                 year:valid_min = 6 ;
> 
> data:
> 
>  year = 9 ;
> }
> $ t
> $ ncdump m.nc
> netcdf m {
> variables:
>         long year ;
>                 year:valid_min = 6. ;
> 
> data:
> 
>  year = 92 ;
> }

I was able to duplicate the problem and it does appear to be a bug.
According to the netCDF User's Guide, the procedure should either fail
or do the right thing.  We'll work on it and let you know what we find.

In the meantime, the "workaround" is to ensure that the attribute type
(originally an NC_LONG) is capatious enough to hold the new type (in
this case an NC_DOUBLE).  In your example, this would mean specifying
the value for the attribute as "6.0" in the original CDL file.

Glenn,

The problem appears to be that, on the Cray Y-MP, the on-disk
representation of an NC_LONG is 4 bytes but the in-memory representation
is 8 bytes.  The library, consequently, allocates 8 bytes of memory
to hold the 4-byte datum.  Since this is is large enough to contain an
NC_DOUBLE, the library doesn't notice a problem when the type is changed
and 8 bytes are subsequently written to the disk.

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