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.
>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