Various improvement in documentation and a decoding function

[bmribler]

• Improves documentation on the type size when creating/accessing a compound datatype with no predefined struct (GH issue Improve documentation for creating a compound datatype with no predefined struct #5371)
• Provides better description of the min_meta_perc and min_raw_perc arguments in the H5Pset_page_buffer_size() (GH issue Provide better description of the min_meta_perc and min_raw_perc arguments in the H5Pset_page_buffer_size() function’s documentation #5711)
• Adds error checkings to an internal decoding function

[jhendersonHDF]

Based on my reading, for most of these functions type_size is used to specify the size of the memory datatype, which may not necessarily be the same size as the file type (for example, if writing from a packed memory compound type). From that, H5TBget_field_info() is probably not what applications should call here. I believe the same advice from above about adding the sizes of the fields plus any structure padding still applies here and for several or all of the functions below.

[fortnern]

I think the question is, if the data is not stored in a C struct, how is it stored? If the application is manually moving bytes around in memory then it should know these values.

[bmribler]

My understanding from @jhendersonHDF's comment tells me that I should use the same description of type_size in H5TBmake_table() for all type_size entries. I'll go ahead with that unless @fortnern thinks otherwise, as your comment seemed to suggest.

[fortnern]

I think that's fine though I added a comment about the method specified for make_table - you only need to look at the field with the highest offset.

[fortnern]

You really just need the last offset plus the size of the last type (and any padding bytes desired after the last member). This is assuming the fields are sorted by offset, otherwise use the highest offest and the size of the type for the field with the highest offset.

[jhendersonHDF]

True, though I was mostly going for simplicity and as you already mentioned if the structure is just an untyped block of bytes the size should generally already be known. I do think the API design and documentation leaves a bit to be desired and telling someone how to calculate the size of their in-memory structure here may just be adding more potential for confusion than necessary.

[bmribler]

How about: "Otherwise, \p type_size should be calculated based on the highest offset in \p field_offset, the size of its corresponding datatype in \p field_types, and any padding bytes desired after that field."