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

Re: 20041203: Bugs? for netcdf-3.5.0 and 3.6.0-beta

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: 20041203: Bugs? for netcdf-3.5.0 and 3.6.0-beta
  • Date: Mon, 06 Dec 2004 15:06:31 -0700
>To: address@hidden
>From: Jianwei Li <address@hidden>
>Subject: Bugs? for netcdf-3.5.0 and 3.6.0-beta
>Organization: Northwestern University
>Keywords: 200412040028.iB40SBlI019765 netCDF

Hi Jianwei,

> There is some potential bugs in the netcdf code. I found this when we
> were developing our parallel-netcdf code and got user feedbacks.
> 
> Basically, in netcdf/src/libsrc/putget.c, for subarray or strided-subarray
> access, the code will first do "NCcoordck(start)" check against dimsize.
> Normally, [start>=dimsize] should be treated as invalid, as in put/get_var1.
> However, vars/vara [start=dimsize, edge=0] seems to be valid, yet the netcdf
> code treats it as invalid and breaks some user code unexpectedly.
> 
> As a result, put/get_vara_xxx(ncid,varid,{start=dimsize},{edge=0},NULL) fails
> in current netcdf code.
> 
> Similar results hold for vars/varm functions.
> 
> It's hard to tell if those cases are conceptually valid or not, but it may
> make programming favorably convenient if it is gracefully handled.

I just tried a fix to handle this gracefully, but find that it makes
some of the tests in nc_test/test_get.c fail, since those tests were
written with the assumption that [start==dimsize, edge==0] should be
treated as invalid.  I agree with you that it really should be valid,
but don't know if it is practical to fix the all the tests to allow
this.  It's too late to get these fixes in 3.6.0, but maybe 3.6.1.
Thanks for reporting the problem!

--Russ