| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this change, libtiff relied on global error handlers,
which is problematic when libtiff used by multiple independent
libraries from within the same process, as they may unwittingly
clobber the error handling, introduce race conditions when setting
handlers, or otherwise have unintended side effects.
This change adds error handlers to the TIFF struct, which are
used preferentially when available. The error handlers are invoked
when the re-entrant error functions are called:
void TIFFErrorExtR(TIFF*, const char* module, const char* fmt, ...)
void TIFFWarningExtR(TIFF*, const char* module, const char* fmt, ...)
The handlers have a similar signature to the existing extended
handlers, additionally returning an int:
int TIFFErrorHandlerExtR(thandle_t, const char*, const char*, va_list)
thandle_t is the userdata passed to TIFFOpen
When the handler returns 1, the global handlers are not called.
Custom error/warning handlers may be installed on a per-file
basis by calling the Set functions:
TIFF* tif = TIFFOpen(...);
TIFFSetErrorHandlerExtR(tif, MyErrorHandler);
TIFFSetWarningHandlerExtR(tif, MyWarningHandler);
Additionally, the callsites to TIFFErrorExt and TIFFWarningExt
have been updated to call the reentrant versions.
|
|\
| |
| |
| |
| | |
Fix CMake build to be compatible with FetchContent
See merge request libtiff/libtiff!394
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Recent versions of CMake have improved support for including
dependencies, using the FetchContent module, which allows a dependency
to be imported as a subproject and then later found automatically by
calls to `find_package`.
This change makes libtiff's CMake better behaved when used as a
sub-project:
- CMake has a single global namespace for all target names in all
sub-projects. This commit renames the following CMake targets:
- port -> tiff_port
- mkg3states -> tiff_mkg3states
- faxtable -> tiff_faxtable
- release -> tiff_release
- When building TIFF as a sub-project, it is not normally useful to
create install rules for its targets. This commit adds a
`tiff-install` option that controls whether the install rules are
added and defaults to OFF when libtiff is included as a sub-project.
- Previously, libtiff set `BUILD_SHARED_LIBS` to ON by default. With
this commit, that default is only set if libtiff is the top-level
project.
- When using `find_package(TIFF)`, the targets `TIFF::TIFF` and
`TIFF::CXX` are defined. This commit makes libtiff itself define
those targets as aliases, to allow other cmake projects to use
either `find_package` or `FetchContent` interchangeably.
- Adds ZSTD_HAVE_DECOMPRESS_STREAM variable which may be set to bypass
`check_symbol_exists` call. Fixes
https://gitlab.com/libtiff/libtiff/-/issues/472.
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Only makes sense in the context of Automake. Was carried over
for reference while porting, but is not needed.
|
|
|
|
|
| |
The functionality provided by the NMake build is now completely
superseded by the CMake build.
|
| |
|
|\
| |
| |
| |
| | |
tiff tools and libtiff/mkg3states: include 'libport.h', remove local definition of 'getopt()'
See merge request libtiff/libtiff!198
|
| | |
|
|/
|
|
| |
at build time)
|
|
|
|
|
|
|
| |
Found with:
codespell --version
1.17.1
|
| |
|
|
|
|
|
|
| |
This is only needed when building with WEBP support, which uses atomics,
therefore the linker needs the --shared-memory flag. The flag cannot be
added globally because not all executables link against libwebp.
|
|
|
|
|
| |
fixes #52
http://bugzilla.maptools.org/show_bug.cgi?id=2469
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
oss-fuzz reports
|
|
|
|
| |
commit
|
| |
|
|
|
|
| |
$LIB_FUZZING_ENGINE
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Most of them were found by codespell.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is possible to craft a TIFF document where the IFD list is circular,
leading to an infinite loop while traversing the chain. The libtiff
directory reader has a failsafe that will break out of this loop after
reading 65535 directory entries, but it will continue processing,
consuming time and resources to process what is essentially a bogus TIFF
document.
This change fixes the above behavior by breaking out of processing when
a TIFF document has >= 65535 directories and terminating with an error.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
purposes of security issue reporting.
|
| |
|
|
|
|
|
|
| |
Roger Leigh (via tiff mailing list on 2015-09-01) to fix issue
with BSD make and to make use of cmake in 'distcheck' target
conditional on if cmake is available.
|
| |
|
| |
|
|
|
|
|
|
|
| |
libtiff mailing list on Mon, 22 Jun 2015 21:21:01 +0100. Several
corrections to ensure that the autotools build still works were
added by me. I have not yet tested the build using 'cmake' or
MSVC with 'nmake'.
|