Description:
- In DataType::DataType(const PredType& pred_type), using DataType::copy
will invoke DataType::close() unnecessarily, which will produce undefined
behavior. Changed to call H5Tcopy directly, code reuse is not useful in
this case.
- Also, fixed CommonFG::childObjVersion to return expected value outside of
an if/else block.
Platforms tested:
Linux/ppc64 (ostrich)
Linux/64 (platypus)
Linux/32 2.6 (jam)
That broke the testings as some testfiles have zlib compressed datasets.
Added options control to enable the linking of zlib external libarary by
default and turn off the szip library linking as szip library may not be
avaiable. This matches the established settings.
Tested: run cmakehdf5 by hand in jam and platypus.
Also tested in wren but it failed in the testing stage.
Also tried "cmakehdf5 --script" in jam. It failed.
Description:
The test added failed in some machines because the data file contains infinity values that different machines print them differently as "inf", "INF", "Inf", ...
Solution:
Added a "ignorecase" option to TOOLTEST() to do caseless matching between generated output vs expected output. This solved most machines problem for now.
Tested: h5committest, emu by hand for both development and production modes.
But cmake built h5dump failed to read the data file. Using the same source to build h5dump by autotools produced a h5dump that can read the test data file. Don't know why cmake could not produce a correct binary.
Description:
- Put back the UNUSED parameters in dsets test because the change to remove
the warning last time caused failure in setting filter, in turn, caused
failure in the test with such obscure/unrelated errors!
- Added incRefCount() to other constructors that missed from last time.
Platforms tested:
Linux/64 (platypus)
Linux/32 2.6 (jam)
SunOS 5.11 (emu)
When the selection is set to all, H5Sextent_copy did not update the number of
elements in the selection in the destination space. Fixed H5Sextent_copy to do
this. Added tests for this functionality.
Tested: jam, koala, ostrich (h5committest)
The tool claimed it could handle 24bit images but there was no code to handle it.
(or might be there were but was removed by previous revisions.)
Also discovered that it does not accept multiple images nor -p for palette
as its user document and online help message indicated.
Solution:
Added code to verify dimension sizes are within 8 bit raster images limit and
added tests to verify the tools correctness.
Need to update user document tool.
Tested: h5committested.
Description:
Per user Jason Newton request, the following constructor is added:
H5File(hid_t existing_id);
Also, fixed H5File::openFile to close current file first before re-using
the object.
Platforms tested:
Linux/64 (platypus)
Linux/32 2.6 (jam gnu and Intel 15.0)
SunOS 5.11 (emu)
Description:
When copy constructor or constructor that takes an existing id is invoked,
the C ref counter stays the same but there is an extra C++ object which
later is destroyed and may cause the HDF5 id to be closed prematurely. The
C++ library needs to increment the ref counter in these situations, so that
the C library will not close the id when it is still being referenced.
However, the incrementing of ref count left some objects opened at the end
of the program, perhaps, due to compiler's optimization on cons/destructors. The constructor, that takes an existing id, needs to increment the counter
but it seems that the matching destructor wasn't invoked. The workaround
is to have a function for each class that has "id" that only sets the id
and not increment the ref count for the library to use in these situations.
These functions are "friend" and not public.
The friend functions are:
void f_Attribute_setId(Attribute *, hid_t)
void f_DataSet_setId(DataSet *, hid_t)
void f_DataSpace_setId(DataSpace *, hid_t)
void f_DataType_setId(DataType *, hid_t)
Platforms tested:
Linux/64 (platypus)
Linux/32 2.6 (jam gnu and Intel 15.0)
SunOS 5.11 (emu)
Bring r26639 from autotools_rework branch to trunk:
Switch AC_TRY_RUN macros to AC_RUN_IFELSE macros.
Tested on:
Linux/32 2.6.18 (jam) w/serial & parallel
(Daily tested on branch for 2+ days)
Description: h52gif crashed when it was asked to convert a 24bitimage.
Upon viewing the code, it did not prepare to handle images other than 2 dimensions.
It has no concept of multiple planes images. Further examinations showed past attempts
to fix it ended up removed some abilities (-p or multiple planes, animation, ...) have
been removed but documentation was not updated. Even its online help message still
shows -p is an option.
Solution: added protection code to flag errors if input request is not an
8bit image within size limits. (I don't have enough knowledge of the GIF
format to fix this tool. All I did was plugging known bug from crashing the
program.)
Tested: h5committest.
Description:
Added wrappers for C functions H5P[s/g]et_libver_bounds and wrappers
for getting object header version
// Sets bounds on versions of library format to be used when creating
// or writing objects.
void setLibverBounds(H5F_libver_t libver_low, H5F_libver_t libver_high) const;
// Gets the current settings for the library version format bounds.
void getLibverBounds(H5F_libver_t& libver_low, H5F_libver_t& libver_high) const;
// Returns the object header version of an object in a file or group,
// given the object's name.
unsigned childObjVersion(const char* objname) const;
unsigned childObjVersion(const H5std_string& objname) const;
Platforms tested:
Linux/64 (platypus)
Linux/32 2.6
SunOS 5.11
Description:
- Changed DataType::operator= to simply copy the id of rhs instead of
calling H5Tcopy because, when the operator= is invoked, a different
datatype id is created and it won't have the same characteristics as
rhs', specifically, if the rhs represents a named datatype, "this"
would still be a transient datatype.
- Added a DataType constructor that takes a PredType object, and this
constructor will cause H5Tcopy to generate another datatype id, from a
predefined datatype.
- Fixed various mistakes in tests.
Platforms tested:
Linux/64 (platypus)
Linux/32 2.6 (jam/gnu and jam/icc 15)
SunOS 5.11 (emu development/production)
Bring r26651 from autotools_rework branch to trunk:
Remove the VSNPRINTF_WORKS macro, it's working around bugs in old SGI
& HP compilers.
Tested on:
Linux/32 2.6.18 (jam) w/serial & parallel
(Daily tested on branch for 2+ days)
Bring r26550 from autotools_rework branch to trunk:
Remove orphaned macro definitions (not attached to anything in the library)
Tested on:
Linux/32 2.6.18 (jam) w/serial & parallel
(Daily tested on branch for 2+ days)
in recent versions of glibc, and -D_DEFAULT_SOURCE is the replacement. Keep
-D_BSD_SOURCE for now to support older systems. gcc will not issue a warning
about -D_BSD_SOURCE being deprecated when -D_DEFAULT_SOURCE is supplied as well.
Tested: jam, koala, ostrich (h5committest)
Bring r26549 from autotools_rework branch to trunk:
Remove the BAD_LOG2_CODE_GENERATED macro/define, it's working around bugs
in old SGI compilers.
Tested on:
Linux/32 2.6.18 (jam) w/serial & parallel
(Daily tested on branch for 2+ days)
Bring r26545 from autotools_rework branch to trunk:
Remove the WANT_DATA_ACCURACY macro/define/configure option, since it's no
longer attached to any library behavior.
Tested on:
Linux/32 2.6.8 (jam) w/serial & parallel
(Daily tested on branch for 2+ days)
Bring r26543 from autotools_rework branch to trunk:
Remove the LLONG_TO_LDOUBLE_CORRECT macro/define, it's working around
bugs in very old SGI/FreeBSD/Windows compilers.
Tested on:
Linux/32 2.6.18 (jam) w/serial & parallel
(Daily tested on branch for 2+ days)
Bring r26513 from autotools_rework branch to trunk:
Remove the LDOUBLE_TO_LLONG_ACCURATE macro/define, it's working around
bugs in older SGI, HP/UX, MacOSX and Windows .NET 2003 compilers.
Tested on:
Linux/32 2.6.18 (jam) w/serial & parallel
(Daily tested on branch for 2+ days)
Bring r26546 from autotools_rework branch to trunk:
Convert AC_TRY_RUN to AC_RUN_IFELSE, for the LDOUBLE_TO_LONG_SPECIAL and
LONG_TO_LDOUBLE_SPECIAL checks.
Tested on:
Linux/32 2.6.18 (jam) w/serial & parallel
(Daily tested on branch for 2+ days)
Bring r26511 from autotools_rework branch to trunk:
Remove the FP_TO_INTEGER_OVERFLOW_WORKS macro/define, which is for working
around bugs in the Cray X1 compiler and is no longer supported.
Tested on:
Linux/32 2.6.18 (jam) w/serial & parallel
(Daily tested on branch for 2+ days)
