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

[Robert D. Vincent]

Steve,

The mtype_id contains the HDF5 type corresponding to the "memory" or
"native" voxel type, and ftype_id contains the HDF5 "file" voxel type.

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.

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?

    -bert

On Tue, Oct 6, 2015 at 1:49 AM, Steve M. Robbins <steve at sumost.ca> wrote:

> Hi,
>
> I'm a little stumped.  The new libminc 2.3.00 fails on certain Debian
> architectures but works on others; see
> https://buildd.debian.org/status/package.php?p=libminc
>
> Mostly, it is minc2-label-test that fails.  The first failure is line 172:
>
>    168    miget_label_value ( vol, "White", &white_value );
>    169    miget_label_value ( vol, "Blue", &blue_value );
>    170
>    171    if (white_value != 0xffffff) {
>    172      TESTRPT("miget_label_value, White", white_value);
>    173    }
>
> Instead of 0x00ffffff, we get -256 = 0xffffff00 -- i.e. a byte-swapped
> value.
> I traced through label.c and found this code that employs "miswap4()".
>  Here
> I'm way over my head, so maybe someone can quickly fill me in:
>
> 1. What are volume->mtype_id and volume->ftype_id ?
>
> 2. Is there any implicit assumptions in this code about the bit-length of
> unsigned short and unsigned int?  Any implicit assumptions about
> endianness?
>
>
>
> int  midefine_label(mihandle_t volume, int value, const char *name)
> {
> ...
>     MI_CHECK_HDF_CALL_RET(result = H5Tenum_insert(volume->mtype_id, name,
> &value),"H5Tenum_insert");
>
>     /* We might have to swap these values before adding them to
>      * the file type.
>      *
>      * COOL! the whole purpose of HDF5 being machine independent is
> defeated
> here!
>      */
>     if (H5Tget_order(volume->ftype_id) != H5Tget_order(volume->mtype_id)) {
>         switch (H5Tget_size(volume->ftype_id)) {
>         case 2:
>             value = miswap2((unsigned short) value);
>             break;
>         case 4:
>             value = miswap4((unsigned int) value);
>             break;
>         }
>     }
>     MI_CHECK_HDF_CALL_RET(result = H5Tenum_insert(volume->ftype_id, name,
> &value),"H5Tenum_insert");
>
>
> Thanks,
> -Steve
> P.S.  See trivial fixes in https://github.com/BIC-MNI/libminc/pull/59
>
>
> _______________________________________________
> 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/20151006/a75fb42f/attachment.html>