[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: Wed, 15 Dec 2004 08:57:37 -0700
>To: address@hidden
>From: Jianwei Li <address@hidden>
>Subject: Re: 20041214: Bugs? for netcdf-3.5.0 and 3.6.0-beta
>Organization: Northwestern
>Keywords: 200412040028.iB40SBlI019765 

Hi Jianwei,

> I found a quick approach to get around the nc_test trouble regarding to
> this new "validity of [start=whatever, edge=0]" semantics. I would just
> disable the "NCcoordck(start)" or similar code section for vara/vars/varm,
> in both libsrc and nc_test/nf_test, since they will run into
> "NCedgeck(start, edge)" or similar code section which can handle the final
> validity check anyway.
> 
> The detailed semantics definition will be up to the designer/developer.
> E.g. instead of always disabling NCcoordck in vara/s/m, they can implement
> conditionally disabling it only when some [edge=0] is detected, so that
> if all [edge > 0] the NCcoordck can still detect invalid [start] ahead
> of NCedgeck.

Thanks for the suggestion.  We're very close to releasing 3.6.0, so
will have to delay this fix until 3.6.1.

--Russ