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
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.