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

[netCDF #BOE-466631]: bug ?

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