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

Re: 961217: C netCDF 2.4.3 problems

>To: address@hidden
>From: "William C. Mattison" <address@hidden>
>Subject: C netCDF 2.4.3 problems.

Hi Bill,

> I'm having a couple problems with the C implementation of netCDF, version
> 2.4.3, functions ncattinq and ncattget:
> 
> 1. The netCDF User's Guide (Feb. 1996) says in section 8.3, page 108, 
> ncattinq,
>    that the int* len returned for attributes of type NC_CHAR includes the
>    terminating zero byte.  So if an attribute has a value "east", I would
>    expect "len" to be returned with a value of 5.  But the "len" values I'm
>    getting back do not include the terminating zero byte.  So for an attribute
>    value of "east", ncattinq actually returns a "len" value of 4 to me.  So
>    either the User's Guide is wrong, or ncattinq has a bug.
>
> 2. The same User's Guide paragraph (the description of the "len" parameter in
>    the ncattinq API suggests that the terminating zero byte is included when
>    I get an NC_CHAR attribute value.  The ncattget example (section 8.4, page
>    110) suggests likewise.  But I never get a terminating zero byte.  In my
>    C++ application, I added 1 to the "len" value returned by ncattinq when
>    calling "new" to allocate a string for the attribute value, yet I still
>    get no terminating zero byte.  So here too, either the User's Guide is
>    implying (though not explicitly stating) something incorrect, or ncattget
>    has a bug.
> 
> I am easily able to work around these bugs (add 1 to "len" before doing the
> "new"; brute force a terminating zero byte into the string value after 
> ncattget
> returns); but it would be good to see either the User's Guide corrected or the
> ncattinq and ncattget bugs fixed.

Thanks for pointing out this inconsistency so clearly.  It turns out
that if you write attributes with the terminating zero byte, e.g.

    ncattput(ncid, varid, "att", NC_CHAR, 5, "east");

then ncattinq returns a length that includes the zero byte, e.g. 5 for
an attribute written as above.  However, if the attribute is written
without the trailing zero byte included in the length provided to the
ncattput call, then as you have reported ncattinq doesn't include the
zero byte in the returned length, in contradiction to what the
documentation says, and ncattget doesn't include the zero byte in the
returned value.

The ncattput documentation says to provide a "len" that includes the
zero byte, so programs that follow this convention would behave
consistently with the documentation.  However, the documentation for the
corresponding FORTRAN function NCAPTC includes no such recommendation,
and FORTRAN programmers may have difficulty null-terminating strings
when storing string-valued attributes, or dealing with strings that
include a trailing zero byte.

Also, the "ncgen" utility with the "-b" option does *not* include the
trailing zero byte when it stores NC_CHAR attributes.  So any file
generated by "ncgen -b" will not store null-terminated string
attributes, and for these files, the attribute lengths returned will not
include a trailing zero byte.

I will clarify the ncattinq and ncattget documentation to be consistent with
the current behavior.

Thanks again for the bug report.

--Russ

_____________________________________________________________________

Russ Rew                                         UCAR Unidata Program
address@hidden                     http://www.unidata.ucar.edu