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 Chuck, > We have long used arrays of strings in our files with NUL characters to > delimit the strings. Here is an example, which can be created with the > attached demo program: > > netcdf simple_char { > dimensions: > n = 8 ; > variables: > char data(n) ; > data: > > data = "abc\000def" ; > } > > > This has always worked well for us. But it turns out that if > ncgen/ncgen3 attempts to process this file, all of these character > variables are truncated at the first NUL, rendering the new file corrupt: > > netcdf simple_char { > dimensions: > n = 8 ; > variables: > char data(n) ; > data: > > data = "abc" ; > } > > > I've reproduced it with versions 3.6.2 and 4.2.1.1. I've read about > related issues regarding attributes in the support forums, but it seems > in cases like this ncgen should be symmetric with ncdump and faithfully > record the embedded NULs. Any thoughts? We've rarely used ncgen, so this > has not been a real issue. But lately we've had a couple cases where > this limitation has caused some heartburn. > > Thanks, and let me know if I can provide more information. I just checked netCDF version 2.4.3 from 1996, and the ncgen then behaved the same way, not preserving data beyond null bytes in char variables. So it looks like a bug that's been around for at least 17 years, and I guess we ought to get around to fixing it :-) . I'll enter a bug ticket for it soon, unless someone can convince me it's a feature ... --Russ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: SAI-630695 Department: Support netCDF Priority: Normal Status: Closed