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 Charlie, > It looks like ncdump/ncgen use simple double quotes for NC_STRING. > How does one disambiguate between NC_CHAR and NC_STRING? > For variables it is not a problem because the type of the > variable is specified in the metadata before the data section. > This is not true for attributes. > The type has to be indicated by some sort of sentinel, e.g., > 1.0f, 1ll, 1us. > Aren't double quotes, alone, ambiguous, in that they could > represent both NC_CHAR and NC_STRING? > > We have (temporarily, perhaps) addressed this ambiguity > in ncap2 by adding an "s" after the quotes to indicate NC_STRING, e.g., > > global@Conventions_NC_CHAR = "CF-1.0"; // NC_CHAR > global@Conventions_NC_STRING = "CF-1.0"s; // NC_STRING > var_foo=1.0; > var_foo@units="meters"s; // NC_STRING > var_foo@units2="meters"; // NC_CHAR This is a good question. I think we need to distinguish char and string attributes to make sure a classic model netCDF-4 file doesn't become a netCDF-4 file inadvertently on a round trip from netCDF to CDL to netCDF via ncdump and ncgen. I'm at a meeting in D.C. all day today and tomorrow, so I may not get to this until the end of the week, but in the limited time I've had to think about it, I think you're right, that we have to fix this ambiguity while preserving as much backward compatibility as practical. Thanks for bringing this to our attention. --Russ