Bug fix.
Description:
Generic property list code wasn't getting initialized early enough to get
the proper values into the macro/constants.
Solution:
Call H5P_init() from H5_init_library().
Platforms tested:
FreeBSD 4.1.1 (hawkwind)
Redo of a patch
Description:
As Quincey pointed out, the parameters are only ``UNUSED'' if we
can't find libz.a.
Solution:
I changed it to conditionally put the UNUSED in there...
Platforms tested:
Linux
Backward compatibility additions
Description:
Created HDF5 v1.2 compatibility API functions (H5Tget_member_dims &
H5Tinsert_array) which use the newer array datatypes underneath, but should
ease user's transition to the 1.4 version of the library.
Platforms tested:
FreeBSD 4.1.1 (hawkwind)
API cleanup
Description:
Tweaked some parts of the generic properties API to reduce warnings.
Platforms tested:
FreeBSD 4.1.1 (hawkwind) & SGI O2K (modi4)
Code updates
Description:
Finished fleshing out code for generic properties, although they are not
used anywhere in the library yet.
Platforms tested:
FreeBSD 4.1.1 (hawkwind)
Bug fix
Description:
"old-style" compound datatypes with array fields were leaking memory
during the datatype header decoding when creating the array datatype for
a field.
Solution:
Free the base type of the array after creating array datatype for field.
Platforms tested:
Solaris 2.6 (baldric)
Bug Fix
Description:
Generic property lists were leaking memory.
Solution:
Tied them into the regular cleanup code called at the library's termination
Platforms tested:
Solaris 2.6 (baldric) & FreeBSD 4.1.1 (hawkwind)
Bug fix.
Description:
Dimension permutations for array datatypes were being skipped over when
datatype information was read from the file (because they aren't used
anywhere in the library currently), but this could cause problems in the
future when they are used for something.
Solution:
Read them in anyway, even if we aren't using them yet.
Platforms tested:
FreeBSD 4.1.1 (hawkwind)
Bug fix.
Description:
When writing data and the dataset needed to be extended, the write call
ended up using the old dataspace extents (prior to the dataspace extend)
and bad parameters would get into the I/O channel, eventually causing it
to dump core.
Solution:
Every time a dataset is extended, throw away the previous dataspace
information and re-retrieve it.
Platforms tested:
FreeBSD 4.1.1 (hawkwind)
* 2000-11-10 Robb Matzke <matzke@llnl.gov>
Changed `class' to `cls' in various places
since the former is a C++ reserved word and some C compilers (like
the one on blue) complain.
* 2000-11-10 Robb Matzke <matzke@llnl.gov> (H5FD_close)
Removed code that resets the H5FD_t
file structure to zero because that struct has already been
freed. This fixes a core dump on some platforms.
Added new function.
Description:
It's often convenient to query the class of a compound datatype's member
to determine if it's an array and the previous way required you to open
the member type to query it's class.
Solution:
Added new H5Tget_member_class function to directly ask for the member type's
class.
Platforms tested:
FreeBSD 4.1.1 (hawkwind)
New Feature
Description:
Added array datatype to library. See documentation at:
http://hdf.ncsa.uiuc.edu/HDF5/planning/DP/ArrayType.html
for complete details on the impact to the library.
Solution:
Changes to the base library include removing the ability of compound
datatype fields to be an array (they can use an array type for the field,
to duplicate the functionality) and adding in the new array datatype
everywhere appropriate. (I hope :-)
Platforms tested:
FreeBSD 4.1.1 (hawkwind)
Purpose:
Bugfix
Description:
Rename the [H5_]HAVE_STRUCT_SOCKLEN_T into [H5_]HAVE_SOCKLEN_T.
Solution:
As pointed out by Bill the socklen_t type isn't a structure if
is it defined by the system headers.
So we should better take out the _STRUCT_ from the defines.
Platforms tested:
Purpose:
Bugfix
Description:
The socklen_t was hardcoded to be defined as int on architectures
other than Linux and SUN (Solaris).
Now it turned out that Solaris isn't consistent in this manner.
Versions earlier than 2.7 do not define this type.
Solution:
Check at configure time whether the socklen_t type is defined
by the system header includes. If not than this type is defined
to be 'int'.
Platforms tested:
Solaris 2.6 and 2.7
Linux
IRIX64
Windows NT (command line configure with both cl abd gcc)
Purpose:
Bugfix
Description:
Added defines for HAVE_SYS_TYPES_H, HAVE_SYS_SOCKET_H, and HAVE_STRUCT_SOCKLENT_T.
Platforms tested:
Solaris 2.6 and 2.7
IRIX64
Linux
Windows NT (command line configure with gcc and cl)
Purpose:
Bug fix.
Description:
The names of some entries did not correspond with the names in the
FUNC_ENTER macro. This would cause inaccuracies during Pablo tracing.
Solution:
The names were changed in FUNC_ENTER to agree with the entry names.
Platforms tested:
Solaris, Irix, AIX, HP Vclass
Purpose:
Fix typos in these files.
Description:
In the functions H5Pset_apl_xxx in these files, the parameters of
FUNC_ENTER do not match the function names. So changed them back
to function names.
Solution:
[details about the changes, algorithm, etc...]
[Please as detail as you can since your own explanation is
better than others guessing it from the code.]
Platforms tested:
No test has been done because these are all typos, no effect on
program.
Bug Fix
Description:
Selections in 1-D dataspaces would get into an infinite loop in
H5S_hyper_select_iterate_mem_opt (called by H5Diterate and
H5Dget_vlen_buf_size) due to some incorrect logic.
Solution:
Handled 1-D cases correctly and get out of loop.
Platforms tested:
Eyeballed...
Purpose:
Bugfix
Description:
Large data files were truncated at the receiver's side.
Solution:
Check against EWOULDBLOCK when sending the data and retry.
Platforms tested:
T3E (other platforms had no such problem).
Bug Fix
Description:
Some of the HRETURN types were incorrect. They were NULL when
they should have been FAIL.
Solution:
Changed the NULLs to FAILs.
Platforms tested:
Linux
Purpose:
Bug fix
Description:
H5FD_close() wiped clean the public information before
closing the FD. This caused problem to the lower level
close() which wants to verify it has indeed handed a valid
file-driver to close because that information is wiped out
prematurely.
Solution:
Moved the public information part cleaning after it is closed.
H5FDmpio.c:
Added in a bunch of assertion to make sure the file handle is indeed
an MPIO file.
Platforms tested:
IRIX64 -64 parallel
* 2000-10-31 Robb Matzke <matzke@llnl.gov> (H5F_dest)
Do not call H5FL_FREE() if the root group
object is null. This fixes a bug in h5ls when that tool is given
a file which is not an hdf5 file.
Bug fix
Description:
There is typo in the H5D_write function which reported the
optimized write failure as a H5E_READERROR.
Solution:
Replaced it with the correct H5E_WRITEERROR code.
Platforms tested:
modi4 parallel (compiled H5D.o only).
Purpose:
Detect whether the system has the netinet/tcp.h header file.
Description:
The Stream VFD uses setsockopt(2) to set TCP_NODELAY on an opened
socket. This constant is defined normally in netinet/tcp.h
except for GNU cc under Windows where this header doesn't exist.
This template header file just contains the
#undef HAVE_NETINET_TCP_H
Platforms tested:
Windows NT, GNU cc
Purpose:
Port to Windows platform
Bug fix
Description:
The Stream VFD is ported to Windows now.
Also fixed a bug where an application terminated when it got a SIGPIPE
due to sending/receiving on a closed socket.
Solution:
The socket stuff is treated different under Windows when using
the MS compilers to build HDF5. They define their own socket datatype
and have closesocket() instead of close(2) to close sockets.
Also there are different header files for all the socket stuff.
So I introduced my own socket decriptor datatype in H5FDstream.h
which should be used to pass in external sockets. This datatype
is mapped to either 'int' (UNIX-type sockets) or 'SOCKET' (Windows).
In the code the error code checking was adapted according to the
socket datatype used. Also, for Windows you have to call a routine
to initialize the Socket layer before using it.
As a kind of bug fix, the process signal mask is now set to ignore
SIGPIPE signals which otherwise cause the application to terminate.
The driver read/write routines catch this and return an error code.
Platforms tested:
Windows NT, both with MS Visual C++ compiler and with GNU cc
It is interesting that when compiling with GNU cc under Windows
it is possible to use both Windows and UNIX-type sockets (either
one or the other). So I check for GNU cc and go for UNIX sockets
if possible.
Bug fix
Description:
Forgot to decrement the number of objects in the group when removing
each one...
Solution:
Decrement the ID count when successfully removing each object from a
group.
Platforms tested:
None yet.
Bug fix
Description:
Fixed a very subtle bug that was corrupting the objects in a group when
H5I_clear_group was called and not all the objects in the group were able
to be cleared.
Solution:
Track whether an object as been deleted from each hash location's linked
list and only destroy the list when all the objects on the list are
actually removed.
Platforms tested:
None yet.
Code optimization
Description:
Minor tweaks throughout the optimized regular hyperslab code to increase
speed. This set of improvements increase the benchmark time from taking
~5.46 seconds to ~4.50 seconds, or around a 20% further speedup.
Platforms tested:
Solaris 2.6 (baldric)
Bug fix
Description:
Recent changes to H5FD_read() added a new argument of type of
data to be written but the MPIO file driver call to H5FD_read()
was not updated. Also, the prototype of H5FD_read() in H5Fprivate.h
was "screened out", thus the compiler could not detect the inconsistency.
With the mismatched arguments, MPIO failed badly.
Solution:
Update the H5FD_read() call with the new parameter. Since the
call is used by H5Dread call so far, it is hardcoded to use
H5FD_MEM_DRAW as the value. If the call is used besides for
H5Dread, this parameter needs to be better defined.
(Still need to fix the prototype being blocked off.)
Platforms tested:
O2K -64 parallel.
Feature symmetry
Description:
A while ago I needed to get the 'type' of data being accessed during writes
to the VFL driver, so I put in code to get the information down there.
Albert asked for the same information during reads, so I've added that in.
Tested:
FreeBSD 4.1.1 (hawkwind)
