Hi Rafal,
Den 29 mars 2017 8:21 fm skrev "Rafal Lichwala" <[email protected]>:
>
> Hi Binh-Minh, All,
>
> Thank you for your reply.
>
> Yes, I know how to solve that finally, but I just think there is an
inconsistency in this (any many more) API functions.
> First call to this function returns size without extra character for \0
at the end of the string, but second call to this function requires size
parameter to count this extra character for \0 at the end.
> I think we should decide if we what to count this extra character for \0
or not and keep consistency in both function calls. So getting "size" value
from the first function call should be directly used in the second call.
I think the API is just trying to be similar to strlen (and many other
APIs), which always return the string length excluding the terminating null
character.
If you think about it, it's logical; the terminating null character is not
part of the string, it's simply, well, the terminator.
> About the h5dump - sure - I know there are different tools which can help
and I actually use HDFView, but this is just for the time of application
development and testing, because the goal is to discover HDF5 file
structure in the application without using any external tools.
>
> Anyway, It seems that was just a minor problem which I had with the HDF5
API, because now the next one looks worse...
>
> Pure C-language API (function-based) seems to work more or less fine, but
when I try to use C++ API I can open the HDF5 file, but when I try to get
the object name (getObjName() method for the top group "." for example) I
get "read access violation" exception...
>
> H5Object::getObjName() function internally uses pure C API where it calls
H5Iget_name() twice: first to get the name size (and build a buffer for
that name) and second to get the name itself. But then this pure C char*
buffer of characters is assigned to std::string which is returned from that
method. The problem is that maybe (but I'm not sure here) due to some
compiler optimizations (made while HDF libraries was compiled - I just use
binaries) this assignment of char* to std::string is not made by copying
the content, but simply reassigning the pointer.
That would indicate a compiler bug, since operator= of std::string is
defined to always make a copy. A compiler is not allowed to optimize that
away if it results in a behavioral change from a user POV.
So I highly doubt that's the reason for your access violation.
It would help to see a minimal code example that exhibits the problem.
Cheers,
Elvis
> Before this method returns, this char* array is deleted so that's why I
get "read access violation" exception when I try to get this string
content...
>
> Can someone please help me in that problem?
>
> This is the code from that method:
>
> H5std_string H5Object::getObjName() const
> {
> H5std_string obj_name(""); // object name to return
>
> // Preliminary call to get the size of the object name
> ssize_t name_size = H5Iget_name(getId(), NULL,
static_cast<size_t>(0));
>
> // If H5Iget_name failed, throw exception
> if (name_size < 0)
> {
> throw Exception(inMemFunc("getObjName"), "H5Iget_name failed");
> }
> else if (name_size == 0)
> {
> throw Exception(inMemFunc("getObjName"), "Object must have a
name, but name length is 0");
> }
> // Object's name exists, retrieve it
> else if (name_size > 0)
> {
> char* name_C = new char[name_size+1]; // temporary C-string
> HDmemset(name_C, 0, name_size+1); // clear buffer
>
> // Use overloaded function
> name_size = getObjName(name_C, name_size+1);
>
> // Convert the C object name to return
> obj_name = name_C;
>
> // Clean up resource
> delete []name_C;
> }
> // Return object's name
> return(obj_name);
> }
>
> Regards,
> Rafal
>
>
>
> W dniu 2017-03-28 o 20:14, Binh-Minh Ribler pisze:
>>
>> Hi Rafal,
>>
>>
>> You'll need to pass in link_name_size+1 to the final call
>> of H5Lget_name_by_idx as well.
>>
>>
>> BTW, you can use h5dump to see the structure of the file, initially.
>>
>>
>> Thanks,
>>
>> Binh-Minh
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Hdf-forum <[email protected]> on behalf of
>> Rafal Lichwala <[email protected]>
>> *Sent:* Tuesday, March 28, 2017 4:26 AM
>> *To:* [email protected]
>> *Subject:* [Hdf-forum] HDF5 API problems
>>
>>
>> Hi,
>>
>> For the purpose of some project I'd like to read HDF5 files in my C++
>> application using HDF5 API.
>>
>> First of all I would like to read entire HDF5 file structure to know
>> where are the groups (their names, attributes etc.) and where I can find
>> datasets.
>> The API functions like H5*iterate (non-recursive version) or H5*visit
>> (recursive version) are rather useless, because their H5*_info_t
>> structures have very limited information about the object on the given
>> level in this structure.
>> Thus I've decided to walk manually through this structure and get as
>> much information as I can for the given object.
>>
>> So...
>>
>> Calling H5Gget_info gives me a number of links at the top ("." group)
>> which then I can ask for details based on their index. Fine.
>> Now, having the link index, I can call H5Lget_name_by_idx to get the
>> link name.
>> First initial call to that function will return the name size and second
>> one will return the link name in the properly prepared buffer of char*.
>>
>> On that stage I found a first problem (a bug I suppose):
>> Let's assume the link name is "foobar", so it has 6 characters.
>> Initial call of H5Lget_name_by_idx returns 6, but when I call it again
>> with "size" parameter set to 6 it fills my buffer with just 5 characters
>> ("fooba") even if the buffer has a proper size of 7 bytes (the 7th for
>> the final \0).
>> So it seems I have to increase size by 1 to get the proper link name.
>> What's the problem here? Maybe it's just my wrong understanding for this
>> API function?
>>
>> Code example (returns "fooba" instead of "foobar" in the "link_name"
>> buffer):
>>
>> // initial call to get name size
>> int link_name_size = H5Lget_name_by_idx(file.getId(), ".",
>> H5_INDEX_NAME, H5_ITER_NATIVE, i, NULL, 0, 0);
>>
>> // one more byte for \0 at the end
>> char *link_name = new char[link_name_size + 1];
>>
>> // final call
>> H5Lget_name_by_idx(file.getId(), ".", H5_INDEX_NAME, H5_ITER_NATIVE, i,
>> link_name, link_name_size, 0);
>>
>>
>> Can someone please explain me what's the problem here?
>>
>> Regards,
>> Rafal
>>
>>
>> _______________________________________________
>> Hdf-forum is for HDF software users discussion.
>> [email protected]
>> http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
>> Twitter: https://twitter.com/hdf5
>>
>>
>> _______________________________________________
>> Hdf-forum is for HDF software users discussion.
>> [email protected]
>> http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
>> Twitter: https://twitter.com/hdf5
>>
>
> --
>
> ***
> Rafał Lichwała
> Poznańskie Centrum Superkomputerowo-Sieciowe
> ul. Jana Pawła II nr 10
> 61-139 Poznań
> e-mail: [email protected]
> ***
>
>
> _______________________________________________
> Hdf-forum is for HDF software users discussion.
> [email protected]
> http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
> Twitter: https://twitter.com/hdf5
_______________________________________________
Hdf-forum is for HDF software users discussion.
[email protected]
http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
Twitter: https://twitter.com/hdf5
