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

[Robert D. Vincent]

Hi Steve,

Well, whatever is happening, I can reproduce it on a MIPS64 emulator now,
so I should be able to fix it.

    -bert
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

_______________________________________________
MINC-development mailing list
MINC-development at bic.mni.mcgill.ca
http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.bic.mni.mcgill.ca/pipermail/minc-development/attachments/20151007/7c0d0c53/attachment.html>