Hi Markus,

Just letting you know that bug HDFFV-10300 was entered for this issue.
We will investigate it and get back to you on this.

Thanks!
-Barbara
h...@hdfgroup.org<mailto:h...@hdfgroup.org>


From: Hdf-forum [mailto:hdf-forum-boun...@lists.hdfgroup.org] On Behalf Of 
Krug, Markus
Sent: Tuesday, September 05, 2017 2:57 AM
To: HDF Users Discussion List
Subject: [Hdf-forum] HDF lib incompatible with HDF file spec?

Dear all,

I just came around an interesting issue.
I implemented the writing of HDF files on an embedded system. The amount of 
functionality I implemented is significant less than the HDF lib offers. So it 
is just tailored to my needs. I implemented everything on base of the HDF 3.0 
file spec. One point of my tailoring was to optimize the file size. Therefore, 
I write every internal block in the HDF files aligned byte-by-byte to the next 
- or padded to the address alignment if it is requested by the HDF file 
specification. The HDF files generated by HDFview or Matlab have plenty of 
space in-between the internal blocks. Sometimes a few hundred bytes. As far as 
I read from the HDF file specification this 'extended padding' is not defined 
at all - not even recommended.
However, this 'extended padding' that is performed by the HDF lib leads to a 
behavior that I would consider as an incompatibility to itself. To demonstrate 
this I attached two HDF files to this email. The first (sizeoptimized.h5) is 
generated by my embedded software and is optimized concerning the file size. It 
contains three compounds with each of them has 2 elements. You should be able 
to open that file in HDFview or similar tools and read all its contents.
The second file (sizeoptimizedextended.h5) is generated by HDFview by adding a 
fourth compound after the sizeoptimized.h5 file was opened in HDFview. You can 
see that the file is partly corrupted. The reason for this is that HDFview (and 
therefore the HDF lib I guess) is not really taking care about the position of 
the internal blocks of a file that it is writing to. It seems to me it has some 
internal mapping of those blocks. This mapping gets applied even if it will 
collide, and therefore corrupt, the existing blocks.
If my observation is correct I think the HDF lib will need a bugfix or the HDF 
file spec will need a description of how the internal blocks are allowed to be 
positioned within a HDF file.
I forgot to mention that I tried to use the HDF lib sources and compile it to 
my system. However, I quit after a couple of days because the way the sources 
are written are not suitable at all to adopt them to an embedded system that 
runs a simplified file system and a real-time operating system - and all of it 
has to fit into a few hundred kilobytes.

Can anyone comment on my observation?


Best Regards
Markus
_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@lists.hdfgroup.org
http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
Twitter: https://twitter.com/hdf5

Reply via email to