Notice that that the code you have modified, is disabled with the
SEPDATA flag.
The SEPDATA flag is used to mark old code relating to PR
https://github.com/Unidata/netcdf-c/pull/2179. ; The old code uses
incorrect code for reclaiming and copying variable length data. The
new code attempts to provide general fixes for it.
This flag is intentionally set to use the new code and at some point,
the old code will be expunged.
Looking at the non-SEPDATA code, it appears to allocate the space with the
required extra space for the trailing NUL termination.
So, it is unclear why this is failing. Any chance you can send/point me
to the
offending file?
=Dennis Heimbigner
Unidata
On 3/6/2023 7:41 PM, John Caron wrote:
Hello friends:
The attached code shows a possible bug in the netcdf C library when
reading "fixed length String" data type in HDF5 files, by not zero
terminating them. The output of that program is:
./testClib
*** nc_inq_grp_ncid =65537
*** nc_inq_varid =0
*** nc_inq_att type=12 attlen = 1
CAPE:units[0] = 'J/kg�U'
The correct answer should be
CAPE:units[0] = 'J/kg'
I think the problem might be in hdf5open.c, line 1904:
/* Copy strings, one at a time, into their new home. Alloc
space for each string. The user will later free this
space with nc_free_string. */
for (i = 0; i < att->len; i++)
{
if (!(att->stdata[i] = malloc(fixed_size))) {
free(contig_buf);
BAIL(NC_ENOMEM);
}
strncpy(att->stdata[i], cur, fixed_size);
cur += fixed_size;
}
This probably should be (note mallocing an extra char to be sure the
string is zero terminated):
for (i = 0; i < att->len; i++)
{
if (!(att->stdata[i] = malloc(fixed_size+1))) {
free(contig_buf);
BAIL(NC_ENOMEM);
}
strncpy(att->stdata[i], cur, fixed_size);
cur += fixed_size;
}
IIUC, these strings are returned as char *, and theres no way to find
out their length from the netcdf API. So they have to be zero
terminated. Otherwise the reading code keeps reading into unallocated
memory, and only stops reading when a zero byte happens to be found.
From comments in the code, it would appear that this type is not used
in files written with the netcdf library. If so, it only affects HDF5
files not written with netcdf library, that use "fixed length String"
data types.
Regards,
John
_______________________________________________
NOTE: All exchanges posted to Unidata maintained email lists are
recorded in the Unidata inquiry tracking system and made publicly
available through the web. Users who post to any of the lists we
maintain are reminded to remove any personal information that they
do not want to be made public.
netcdfgroup mailing list
netcdfgroup@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
https://www.unidata.ucar.edu/mailing_lists/
