[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 20000830: problem with ncattinq
- Subject: Re: 20000830: problem with ncattinq
- Date: Wed, 30 Aug 2000 16:56:54 -0600
>To: netCDF Support <address@hidden>
>From: Charlie Zender <address@hidden>
>Subject: problem with ncattinq
>Organization: UC Irvine
>Keywords: 200008292242.e7TMgCN17312
Hi Charlie,
> The return code from ncattinq() (netCDF2) is 1 (incorrect) and the
> return code from nc_inq_att() (netCDF3) is 0 (correct) when I access
> the same file (appended below):
>
> /* fxm: 20000829 ncattinq() produces non-zero return code for no reason */
> rcd=ncattinq(nc_id,var->id,"scale_factor",&scl_fct_typ,&scl_fct_lng);
> /* fxm: 20000829 nc_inq_att behaves fine but requires netCDF 3 */
> rcd=nc_inq_att(nc_id,var->id,"scale_factor",&scl_fct_typ,(size_t
> *)&scl_fct_lng);
>
> In the ncattinq case, the type and length are set correctly but the
> return value is incorrect, which causes my program to bomb. I need
> the netcdf2 compatibility. Any ideas?
You probably won't like this answer, but Actually the return code from
ncattinq() is correct, because the documentation for ncattinq said
only that it returned -1 in case of error. What it returned on
success was never explicitly documented, as was the case for many
other netCDF2 functions. In netCDF version 2.4.3 and all other
versions I am aware of, it returned 1 on success, but the only valid
tests according to the documented interface test against -1:
if (ncattinq(ncid, varid, ...) != -1) {
/* success */
} else {
/* failure */
}
If we changed the return now to match the netCDF3 return code of
NC_NOERR (0) on success, it might break other netCDF2 programs that
went beyond the documented interface and treated 1 as a successful
return.
See netcdf/src/libsrc/v2i.c for the source code for netCDF2 backward
compatibility, where the ncattinq code explicitly returns 1 on success
rather than the returned status from nc_att_inq() to preserve complete
backward compatibility with the netCDF2 behavior.
Sorry about that ...
--Russ