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)
Bring r26508 from autotools_rework branch to trunk:
Remove HW_FP_TO_LLONG_NOT_WORKS macro/define, it was only addressing
Windows .NET 2003 compiler issues.
Tested on:
Linux/32 2.6.18 (jam) w/serial & parallel
(Daily tested on branch for 2+ days)
Bring r26503 & r26528 from autotools_rework branch back to the trunk:
Remove old platform configure files: craynv, dec-flags, hpux11.23,
ia64-linux-gnu, nec-superux14.1, sv1-cray, x86_64-redstorm-linux-gnu
Also remove CONVERT_DENORMAL_FLOAT, since this was only set in the
configure files being removed.
Tested on:
Linux/32 2.6.18 (jam) w/serial & parallel
(Daily tested on branch for 2+ days)
Bring r26502 from autotools_rework branch to trunk:
Remove the H5_SW_ULONG_TO_FP_BOTTOM_BIT_WORKS and
H5_FP_TO_ULLONG_BOTTOM_BIT_WORKS macros/defines, as they are no longer used by
supported platforms.
Tested on:
Linux/32 2.6.18 (jam) w/serial & parallel
(Daily tested on branch for 2+ days)
Bring r26501 from the autotools_rework branch to the trunk:
Remove ULLONG_TO_LDOUBLE_PRECISION macro/define, as it's targeting bugs
in the FreeBSD and Cygwin compilers.
Tested on:
Linux/32 2.6.18 (jam) w/serial & parallel
(Daily tested on branch for 2+ days)
Bring r26500 from autotools_rework branch to trunk:
Remove the LLONG_TO_FP_CAST_WORKS macro/define, as it targets problems with
the Visual Studio 6 compilers.
Tested on:
Linux/32 2.6.18 (jam) w/serial & parallel
(Daily tested on branch for 2+ days)
Bring r26499 from autotools_rework branch to trunk:
Remove ULLONG_TO_FP_CAST_WORKS macro/define, as it only applies to older
platforms we aren't supporting any longer.
Tested on:
Linux/32 2.6.18 (jam) w/serial & parallel
(Daily tested on branch for 2+ days)
Bring r26494 from autotools_rework branch back to trunk:
Remove the LDOUBLE_TO_UINT_ACCURATE macro/define, it was addressing
problems with older Intel compilers on Linux that are no longer supported.
Tested on:
Linux/32 2.6.18 (jam) w/serial & parallel
(Daily tested on branch for several days)
Bring r26492 from autotools_rework branch back to trunk:
Remove the FP_TO_ULLONG_ACCURATE and FP_TO_ULLONG_RIGHT_MAXIMUM
macros/defines, which were added to address problems with older PGI
compilers and HP-UX systems and are no longer supported.
Tested on:
Linux/32 2.6.18 (jam) w/serial & parallel
(daily tested on branch for >1 week)
Bring r26489 from autotools_rework branch to trunk:
Remove the ULONG_TO_FP_BOTTOM_BIT_ACCURATE macro/define, as it was added
for SGI systems and old Solaris systems, which are no longer supported.
Tested on:
Linux/32 2.6.18 (jam) w/serial & parallel
(Daily tested for >1 week)
Bring r26485 from the autotools_rework branch to the trunk:
Remove the ULONG_TO_FLOAT_ACCURATE macro/define, we no longer support the
Sandia system where it was necessary.
Tested on:
Linux/32 2.6.18 (jam) w/serial & parallel
(daily tested for >1 week)
