[MINC-development] test failures: minc2-label-test

[Steve M. Robbins]

Thanks, Bert,

> My memory here is a little weak, but I think we tried to create parallel
> HDF5 types for volumes, such that the "native" type would be in the
> machine's byte order, but the file type would always be little endian. My
> guess is that the H5Tenum_insert() function does not do any translation of
> its argument, so that we needed to swap bytes to keep the label values
> consistent on big-endian architectures.

Did you write that backwards?  The test failures coincide with big-endian 
machines -- the little endian ones all pass (except mipsel, which fails on a 
different test).

What is even more confusing to me is that the test code's function 
create_label_image() actually defines the labels and then tests them -- with 
no failures -- using the same miget_label_value() call that later fails at 
Line 172.  The difference I can see is that the first test operates on a 
volume created in memory and the second operates on a volume read from disk.  
Does that mean one is using 'mtype' and the other 'ftype'?  [That doesn't 
appear to be the case -- the code of miget_label_value() seems to use only 
mtype.]



> 
> Once upon a time, we regularly tested on big-endian machines, but that is
> rare these days. It's certainly possible that there are assumptions about
> either the byte order or type sizes.
> 
> Do you happen to know the HDF5 version in use?

All use 1.8.15, except ppc64 which runs 1.8.13.

-Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part.
URL: <http://www.bic.mni.mcgill.ca/pipermail/minc-development/attachments/20151007/b6534b73/attachment.pgp>