hdf5
hdf5 copied to clipboard
HDFGroup
Regression with 1.14.4-3 H5Fcreate opens and close file with wide chars (example chinese characters)
Previously with 1.12.1 on windows x64 build, this code works as expected with filename = L'漢字.nh5'
std::string utf_filename = wstring_to_utf8(filename);
hid_t plist_id = H5Pcreate(H5P_FILE_CREATE);
H5Pset_userblock(plist_id, 512);
hid_t plist_ap = H5Pcreate(H5P_FILE_ACCESS);
#if H5_VERSION_GE(1, 10, 2)
H5Pset_libver_bounds(plist_ap, H5F_LIBVER_EARLIEST, H5F_LIBVER_V18);
#endif
hid_t fid = H5Fcreate(utf_filename.c_str(), H5F_ACC_TRUNC, plist_id, plist_ap);
// fid OK no error
H5Pclose(plist_id);
herr_t status = H5Fclose(fid);
if (status < 0) {
delete[] header_offset;
delete[] header_saturated;
return -1;
}
// status OK
#ifdef _MSC_VER
FILE* fp = _wfopen(filename.c_str(), L"r+b");
#else
FILE* fp = fopen(utf_filename.c_str(), "r+b");
#endif
if (fp == nullptr) {
// HERE FILE WAS NOT CREATED !!!
}
file was not created by H5FCreate
What do I miss ?
I think I have tracked down the cause of this - see #5037. Thanks @jhendersonHDF for pointing me to this issue.
The change which affected 1.14.3 was reverted in 1.14.6 - see #5037. The issues weren't closed because HDF group want to find a better solution.
Yes, we'd like to find a better solution that addresses the issue described in https://github.com/HDFGroup/hdf5/pull/4172 while also not breaking the previous behavior relied upon by h5py and other software. But @Nelson-numerical-software, if you can confirm that 1.14.6 works for you in this case, I think we can go ahead and close this issue after adding a test case.
I just build 1.14.6 using vcpkg (x64 and x86). I confirm that 1.14.6 works as expected with wide char.
Great, thanks! Will go ahead and close this issue and the other related one and create a follow-on issue to capture details about what we need to do going forward.