Howdy,
When fetching a string attribute using h5ltget_attribute_string_f(), the string returned seems to be a C string i.e null terminated, even when using the Fortran interface. Thus, one could set an attribute of length 10 and immediately read it and get an 11-character string (to accommodate the null character). Do ya'll consider this a bug? Any chance at nipping off that null character before returning?
Cheers,
-Corey
PS. Read earlier that the dimension scales are getting added to the Fortran interface! Thanks! You'll have at least one user of that feature!
Howdy,
When fetching a string attribute using h5ltget_attribute_string_f(), the string returned seems to be a C string i.e null terminated, even when using the Fortran interface. Thus, one could set an attribute of length 10 and immediately read it and get an 11-character string (to accommodate the null character). Do ya'll consider this a bug? Any chance at nipping off that null character before returning?
Yes, the NULL termination should be removed before returning the string (the Fortran string will be blank padded if needed). *I think* all the other HL fortran APIs which return a string remove the null termination (the Fortran HL DS APIs definitely do).
What is the current and the correct behaviour of
h5ltget_attribute_info_f regarding
the type_size dummy argument when the attribute is a character string?
The Fortran binding should probably decrement type_size by the appropriate
amount to account for the missing null character. Then users can query
their system the length in bytes of the native sharacter type (of length 1)
and then divide the # of bytes returned in type_size by the number of bytes
in a length 1 native string. (i.e. to use with allocatable scalar character
variables.) Does this sound reasonable/true?
When fetching a string attribute using h5ltget_attribute_string_f(), the
string returned seems to be a C string i.e null terminated, even when using
the Fortran interface. Thus, one could set an attribute of length 10 and
immediately read it and get an 11-character string (to accommodate the null
character). Do ya'll consider this a bug? Any chance at nipping off that
null character before returning?
Yes, the NULL termination should be removed before returning the string
(the Fortran string will be blank padded if needed). *I think* all the other
HL fortran APIs which return a string remove the null termination (the
Fortran HL DS APIs definitely do).
Thanks for pointing this out.
===================================
(301)244-9367
Princeton University Doctoral Candidate
Mechanical and Aerospace Engineering
ibeekman@princeton.edu
Currently in h5ltget_attribute_info_f, if the attribute is a character string then type_size will include the NULL termination in the size. The user will have to adjust the size appropriately.
In general, the Fortran wrappers should return a string with the null character removed and return a string's length/size that do not include the null character. For this HL API, that is not the case.
What is the current and the correct behaviour of
h5ltget_attribute_info_f regarding
the type_size dummy argument when the attribute is a character string?
The Fortran binding should probably decrement type_size by the appropriate
amount to account for the missing null character. Then users can query
their system the length in bytes of the native sharacter type (of length 1)
and then divide the # of bytes returned in type_size by the number of bytes
in a length 1 native string. (i.e. to use with allocatable scalar character
variables.) Does this sound reasonable/true?
Also note, currently some of the C HL DS functions do and do not include the NULL character in the returned length.
For example, H5DSset_scale returns a size which includes the NULL termination. H5DSget_label does not include the NULL termination in the returned size.
When fetching a string attribute using h5ltget_attribute_string_f(), the
string returned seems to be a C string i.e null terminated, even when using
the Fortran interface. Thus, one could set an attribute of length 10 and
immediately read it and get an 11-character string (to accommodate the null
character). Do ya'll consider this a bug? Any chance at nipping off that
null character before returning?
Yes, the NULL termination should be removed before returning the string
(the Fortran string will be blank padded if needed). *I think* all the other
HL fortran APIs which return a string remove the null termination (the
Fortran HL DS APIs definitely do).
Thanks for pointing this out.
What is the current and the correct behaviour of
h5ltget_attribute_info_f regarding
the type_size dummy argument when the attribute is a character string?
The Fortran binding should probably decrement type_size by the appropriate
amount to account for the missing null character. Then users can query
their system the length in bytes of the native sharacter type (of length 1)
and then divide the # of bytes returned in type_size by the number of bytes
in a length 1 native string. (i.e. to use with allocatable scalar character
variables.) Does this sound reasonable/true?
Izaak Beekman
(301)244-9367
Princeton University Doctoral Candidate
Mechanical and Aerospace Engineering
ibeekman@princeton.edu
