Comment 42 for bug 1765503

(In reply to Paul van Haren from comment #18)
> Dear Stephane,
>
> I think you're overlooking the observation by Nikolay (close to the bottom of comment 11):
>
> # Brief analysis
>
> I believe that root cause of the problem is change of `hid_t` datatype in HDF library.
>
> It is not an `int` anymore, it is `int64_t`.
> But the scilab source code have many places with hardcoded `int`.
> See for example `openHDF5File` - http://cgit.scilab.org/scilab/tree/scilab/modules/hdf5/src/c/h5_fileManagement.c which calls `H5Fopen`:
>
> ```
> int openHDF5File(const char *name, int _iAppendMode)
> {
> hid_t file;
> ...
>
> file = H5Fopen(filename, H5F_ACC_RDONLY, H5P_DEFAULT);
> ...
> return file;
> }
> ```
> Best regards, Paul

I have understood the problem and one of the possible fixes is to redefine hid_t to int (as in the link I gave) as hdf5 1.10 seems to accept it. But I don't understand the logic of Nikolay's patch. I see for example

- hid_t iFile = openHDF5File(filename.data(), 0);
+ int iFile = openHDF5File(filename.data(), 0);

In the piece of code your gave, the logic would be to define the output type of openHDF5File as hid_t. If you declare the "file" id as an int the destructive conversion will occur in the call "file = H5Fopen..." since H5Fopen() yields an hid_t. So instead of changing type in the (many) calls it is simpler to change the output type of the function.