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

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

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>