Hi Ray,
thanks for giving it a look. Antonio made me notice that something else
might be at work since the macro DETECT_F already zeroes the structure
right before anything else:
memset(&INFO, 0, sizeof(INFO)); #L299
so I don't understand how the perm fields need to be zeroed again around
line #L308. This still considering the "Byte Order" loop as a black box.
As a side question: isn't there a more portable way of doing this? I am
pretty sure H5detect.c might invoke a bunch of undefined behaviours given
the amount of warning the compiler generates and of bit trickery.
Best wishes,
Andrea
On 4 September 2013 05:43, Raymond Lu <songy...@hdfgroup.org> wrote:
> Andrea,
>
> We've verified that your solution is correct. We're putting your fix into
> the library. Thanks for helping us.
>
> Ray
>
> On Sep 3, 2013, at 3:32 AM, Andrea Bedini wrote:
>
> Hi there,
>
> I think I have found the problem. The issue is in H5detect.c.
> Macros DETECT_F and DETECT_I do not initialize properly the perm field in
> the detected_t struct. As a result the routine fix_order is passed some
> uninitialized memory which makes it fail. I have a small patch against
> H5detect.c which fixes the problem by simply initializing the perm field
> with zeros. Valgrind's tool memcheck would have exposed the problem.
>
> Best wishes,
> Andrea
>
>
>
> On 3 September 2013 15:30, Andrea Bedini <andrea.bed...@gmail.com> wrote:
>
>> Hi,
>>
>> I am experiencing the following issue with hdf5 and gcc 4.8.0
>>
>> Consider this very simple test
>>
>> #include <hdf5.h>
>>
>> int main() {
>> switch (H5Tget_order(H5T_NATIVE_LDOUBLE)) {
>> case H5T_ORDER_LE:
>> printf("H5Tget_order(H5T_NATIVE_LDOUBLE) = H5T_ORDER_LE\n");
>> break;
>> case H5T_ORDER_BE:
>> printf("H5Tget_order(H5T_NATIVE_LDOUBLE) = H5T_ORDER_BE\n");
>> break;
>> case H5T_ORDER_VAX:
>> printf("H5Tget_order(H5T_NATIVE_LDOUBLE) = H5T_ORDER_VAX\n");
>> break;
>> case H5T_ORDER_MIXED:
>> printf("H5Tget_order(H5T_NATIVE_LDOUBLE) = H5T_ORDER_MIXED\n");
>> break;
>> case H5T_ORDER_NONE:
>> printf("H5Tget_order(H5T_NATIVE_LDOUBLE) = H5T_ORDER_NONE\n");
>> break;
>> default:
>> printf("here are dragons\n");
>> }
>> return 0;
>> }
>>
>> on the same x86_64 GNU/Linux machine I get
>>
>> $ hdf5-1.8.11-gcc-4.7.0/my_test # compiled with gcc 4.7.0
>> H5Tget_order(H5T_NATIVE_LDOUBLE) = H5T_ORDER_LE
>>
>> $ hdf5-1.8.11-gcc-4.8.0/my_test # compiled with gcc 4.8.0
>> H5Tget_order(H5T_NATIVE_LDOUBLE) = H5T_ORDER_VAX
>>
>> So H5T_NATIVE_LDOUBLE is mis-detected. I tried to dig deeper and
>> basically the fault must be in src/H5detect.c which is used to generate the
>> definitions in src/H5Tinit.c
>> I could not figure out what H5detect.c does wrong (it is not very
>> readable, given its extensive use of macros) but the compiler does emit a
>> lot of warnings (see https://gist.github.com/andreabedini/6419975).
>>
>> I think this must be related to the failure of dt_arith long double test
>> observed recently.
>>
>> Any suggestion on how to fix this ?
>>
>> Best wishes,
>> Andrea
>>
>>
>> --
>> Andrea Bedini <andrea.bed...@gmail.com>
>>
>
>
>
> --
> Andrea Bedini <andrea.bed...@gmail.com>
> <hdf5_uninitialized.patch>_______________________________________________
> Hdf-forum is for HDF software users discussion.
> Hdf-forum@lists.hdfgroup.org
>
> http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
>
>
>
> _______________________________________________
> Hdf-forum is for HDF software users discussion.
> Hdf-forum@lists.hdfgroup.org
>
> http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
>
>
--
Andrea Bedini <andrea.bed...@gmail.com>
_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@lists.hdfgroup.org
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
