Previously, ph5diff may hang in a test in Linux 32 platform(HDFFV-587).
No solution was available and a patch to bypass the test is implemented.
Since the company is changing domain name soon, the patch would not be valid any more.
Tests were done (repeat 100 mpiexec -np 6 ./ph5diff -v h5diff_hyper1.h5 h5diff_hyper2.h5)
and the previous hanging problem did not occur. It is likely the newer versions of
mpich no longer have this problem. Therefore, it is decide to remove this patch
to make the test script cleaner, if nothing else.
Tested: ran build and test in Jam (linux 32) and the repeat 100 command mentioned above.
All passed.
Revert r25273, 25283 & 25439 (the hyperslab improvement changes). They
are buggy and it's taking me a long time to correct the problem. I'll check
in a revised form of the changes when I've got them straightened out.
Tested on:
Mac OSX 10.10.0 (amazon) w/gcc 4.9.x, C++, FORTRAN
Linux 2.6.x (jam) w/parallel
script. The warnings that this generates cannot easily be resolved in
platform-independent C code since gnu expects the non-standard (gnu)
'D' suffix for double constants.
It's still technically useful for catching float and long double
constants, but should probably be enabled by developers on an
as-needed basis for that purpose so the spurious warnings are
avoided.
Tested on a local linux VM with gcc 4.8.2. This is a very minor change.
Discovered when I temporarily #defined HDfree() to a more complicated
function while investigating something.
Tested on a local linux VM. This is a very minor change.
but the test was not changed (still doing H5A_create(...) < 0).
Fixed the error by changing to compare against NULL.
Tested: ADA AIX machine where the old code was flagged as an error by the AIX compiler.
Did not provide default values for clang++ options.
Also, applied wrong values for the *_CPPFLAGS.
Solution:
Added default values for *_CXXFLAGS.
Fixed the *_CPPFLAGS values.
Tested: wren with and without --enable-production.
Description:
Added notes regarding UTF-8 and extended ASCII, provided in HDFFV-8899,
to C++ API.
Platforms tested:
Linux/32 2.6 (jam) - only in comments
Description:
Mac has changed to use the clang/clang++ compilers but compiler settings for production, debug and profile
were not setup.
Solution:
Setup default values for PROD_CFLAGS, PROD_CPPFLAGS, DEBUG_CFLAGS, DEBUG_CPPFLAGS.
PROFILE_CFLAGS and PROFILE_CPPFLAGS were set too but clang does not -pg or such for
profiling. Need to fix it later.
Tested: duck, swallow, and quail using --enable-production.
Removed the try/block with new/bad_alloc that were unintentionally
committed previously.
Platforms tested:
Linux/ppc64 (ostrich)
Linux/32 2.6 (jam)
SunOS 5.11 (emu)
Description:
Followed hints on the JIRA issue to remove several potential memory
leaks.
Platforms tested:
Linux/ppc64 (ostrich)
Linux/32 2.6 (jam)
SunOS 5.11 (emu)
Description:
- Used H5I_INVALID_HID instead of 0 to initialized member "id" in classes
that represent HDF5 objects. For PropList, H5P_DEFAULT has to be used
instead of H5I_INVALID_HID.
- Added try/catch block to some dynamically allocating memory code and
re-throw the bad_alloc exception with a message informing the location of
the failure.
Platforms tested:
Linux/ppc64 (ostrich)
Linux/32 2.6 (jam)
SunOS 5.11 (emu)
Description:
H5F_ACC_CREAT was included in the C++ API while the C library doesn't
allow it yet. Possibly, in the future, but not now. In addition, the
two flags H5F_ACC_RDONLY and H5F_ACC_RDWR were missing from the
documentation, causing confusion that appending is not supported.
Solution:
- Removed H5F_ACC_CREAT from the function until the C library support it
- Added H5F_ACC_RDONLY and H5F_ACC_RDWR to the comments to update the
documentation
Platforms tested:
Linux/ppc64 (ostrich)
Linux/32 2.6 (jam)
SunOS 5.11 (emu)
as NULL. The library is supposed in that case to equally divide the
address space among all members, but there was a bug causing an
overflow in the assignment.
tested with h5commitest
