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.
Hi Charles, I believe the problem is assuming that text attributes returned by nc_get_att_any() are null-terminated and that the length returned by ncattinq() includes a '\0' byte for such null termination. In fact, attributes in a netCDF file are language neutral, so that Fortran, C, and Java programs can all get attribute values and interpret them correctly. That means the attribute length just refers to the number of characters in the attribute array, not including a terminating null byte needed for C applications. The documentation for the nc_inq_att functions points this out under the description for the length argument: lenp Pointer to location for returned number of values currently stored in the attribute. For attributes of type NC_CHAR, you should not assume that this includes a trailing zero byte; it doesn't if the attribute was stored without a trailing zero byte, for example from a FORTRAN program. Before using the value as a C string, make sure it is null-terminated. ... It is also documented for the nc_get_att_text() function "tp" argument: tp Pointer to location for returned attribute value(s). All elements of the vector of attribute values are returned, so you must allocate enough space to hold them. For attributes of type NC_CHAR, you should not assume that the returned values include a trailing zero byte; they won't if the attribute was stored without a trailing zero byte, for example from a FORTRAN program. Before using the value as a C string, make sure it is null-terminated. If you don't know how much space to reserve, call nc_inq_attlen first to find out the length of the attribute. This should probably be made into an FAQ, as it has tripped up other users (including me) and is arguably an error in the way the C interface was designed, but our commitment to backward compatibility makes it impractical to correct now. --Russ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: BOE-466631 Department: Support netCDF Priority: Normal Status: Closed