summaryrefslogtreecommitdiffstats
path: root/hl/examples/ex_table_10.c
diff options
context:
space:
mode:
authorQuincey Koziol <koziol@hdfgroup.org>2008-01-13 05:37:00 (GMT)
committerQuincey Koziol <koziol@hdfgroup.org>2008-01-13 05:37:00 (GMT)
commitd6e767c21d28c9295e24dfedcbcf17c2d18006b8 (patch)
treedb928b7453fdb67016a72f1c737434166d6e773b /hl/examples/ex_table_10.c
parentd9bc27b53521042e9fd648e9c0f0318d0bca4631 (diff)
downloadhdf5-d6e767c21d28c9295e24dfedcbcf17c2d18006b8.zip
hdf5-d6e767c21d28c9295e24dfedcbcf17c2d18006b8.tar.gz
hdf5-d6e767c21d28c9295e24dfedcbcf17c2d18006b8.tar.bz2
[svn-r14402] Description:
Add work-around to allow reading files that were produced with a buggy earlier version of the library, which could create objects with the wrong object header message count. There is now a configure flag "--enable-strict-format-checks" which triggers a failure on reading a file with this sort of corruption (when enabled) and allows the object to be read (when disabled). The default value for the "strict-format-checks" flag is yes when the "debug" flag is enabled and no when the "debug" flag is disabled. Note that if strict format checks are disabled (allowing objects with this particular kind of corruption to be read) and the file is opened with write access, the library will re-write the object header for the corrupt object with the correct # of object header messages. This closes bugzilla bug #1010. Tested on: FreeBSD/32 6.2 (duty) in debug mode FreeBSD/64 6.2 (liberty) w/C++ & FORTRAN, in debug mode Linux/32 2.6 (kagiso) w/PGI compilers, w/C++ & FORTRAN, w/threadsafe, in debug mode Linux/64-amd64 2.6 (smirom) w/default API=1.6.x, w/C++ & FORTRAN, in production mode Linux/64-ia64 2.6 (cobalt) w/Intel compilers, w/C++ & FORTRAN, in production mode Solaris/32 2.10 (linew) w/deprecated symbols disabled, w/C++ & FORTRAN, w/szip filter, in production mode Mac OS X/32 10.4.10 (amazon) in debug mode Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in production mode
Diffstat (limited to 'hl/examples/ex_table_10.c')
0 files changed, 0 insertions, 0 deletions