NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi, Perhaps your Fortran program should check for a trailing \0, and not make any assumptions? The more I think about it, the more it seems like a bad idea to add a \0, however I suspect it will be a long time before all software will write attributes with/without \0. Here is what I do when writing attributes in C: strcpy(attribute,"joe bloggs\0"); nc_put_att_text(ncid, var_id, "attname", strlen(attribute), attribute); This seems a reasonably "natural" way to write an attribute. Even though the C string contains a \0, by the time it reaches the NetCDF file it won't have a \0 (because strlen doesn't count the \0 character). So IDL must be making a special effort to keep the \0 at the end. ------------------------------------------------------------------------ Tim Hume Meteorological Service of New Zealand PO Box 722 Wellington New Zealand ------------------------------------------------------------------------ > > Hello all > > I started writing the following as a bug report to the IDL people, but now > I'm not so sure. Perhaps the netCDF experts could give a ruling on this > matter: > > When an application writes text data to a netCDF file attribute, > should it (may it, must it) terminate the data with a null character? > > I am writing netCDF files with IDL (http://www.researchsystems.com/) and > reading them in a Fortran program. My Fortran program is reading an > attribute and interpreting its value as the name of a variable in the same > netCDF file. I had a very frustrating time working out why it did not find > the variable, when it was very obviously there, until it dawned on me that > it was a string termination issue. I established that the Fortran program > was reading the attribute value as > > wind_time\0 > > where "\0" stands for the ASCII null character and of course it couldn't > find a variable with a name that matched this. > > So I thought, "It's a bug in IDL. When it writes a string value to a netCDF > attribute, it's adding an ASCII null at the end." > > On reading the IDL documentation, I noted the following in the documentation > for NCDF_ATTINQ (IDL's counterpart to the NF_INQ_ATT family): > > Length > > The number of values stored in the attribute. If the attribute > is a string, the number of values indicates one more character > than the string length to include the terminating null character. > This is the NetCDF convention... > > It's not a bug it's a feature! But it was news to me that terminating 0s > are a netCDF convention, so I looked in the netCDF documentation. > There are references to this issue in a few places in the C and Fortran > user guides. These are the most relevant: > > Section 8.3 (Get Information about an Attribute: nc_inq_att Family) of the C > guide includes the following > > http://www.unidata.ucar.edu/packages/netcdf/guidec/guidec-13.html > #HEADING13-265 > > 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. If this parameter is > given as '0' (a null pointer), no length will be returned so no > variable to hold this information needs to be declared. > > So this implies it is permissible but not compulsory to add a trailing zero > byte. > > Section 7.15 (Reading and Writing Character String Values) of the Fortran > guide > > http://www.unidata.ucar.edu/packages/netcdf/guidef/guidef-12.html > #HEADING12-1332 > > includes the following > > In FORTRAN, fixed-length strings may be written to a netCDF > dataset without a terminating character, to save space. > Variable-length strings should follow the C convention of writing > strings with a terminating zero byte so that the intended length > of the string can be determined when it is later read by either C > or FORTRAN programs. > > I'm not sure what "variable-length strings" means in this context. Surely > the issue is not whether the string being written has variable length > but whether the reading application has enough info to determine > the string length without the zero byte. For an attribute the size is > available from NF_INQ_ATTLEN so the zero byte is unnecessary IMO. > > I note that when I take a file with a null-terminated text attribute, > convert it to CDL with ncdump, then reconvert it to binary with ncgen, the > trailing zero byte is stripped off (which of course provides me with a > simple way to "fix" IDL-generated files). This suggests to me that > null-terminated text attributes are *not* a netCDF convention. Mind you, > the ncdump man page calls this a bug! > > Any comments? > > --- > Mark Hadfield > m.hadfield@xxxxxxxxxxx http://katipo.niwa.cri.nz/~hadfield > National Institute for Water and Atmospheric Research > > >
netcdfgroup archives: