| Age | Commit message (Collapse) | Author |
|---|
|
SIZE_MAX is surprisingly supposed to be in stdint.h, but Android
headers for API levels < 21 accidentally put SIZE_MAX in limits.h.
Headers for API levels >= 21 correctly moved SIZE_MAX to stdint.h.
This is the situation for Android NDK r14 and earlier.
Android NDK r15 and later implement a header unification strategy:
all sets of headers for each API level are combined into a single
set of headers covering all API levels. Any differences are
expressed by #ifdeffing on __ANDROID_API__. When this was done
the moving of SIZE_MAX from limits.h to stdint.h was kept and,
importantly, no #ifdefs were used in limits.h/stdint.h concerning
SIZE_MAX. This means that the move of SIZE_MAX was retroactively
introduced for API levels < 21 in Android NDK r15 and later.
For this reason whenever mupdf uses SIZE_MAX it must include both:
* stdint.h (not just in order to follow the POSIX specification,
but also to compile successfully using Android NDK r15 and later)
* and limits.h (in order to compile successfully using Android NDK
r14 and earlier)
Hence these need to include both stdint.h and limits.h, because:
* source/fitz/memory.c uses SIZE_MAX
* source/fitz/store.c uses SIZE_MAX
The mupdf header include/mupdf/fitz/system.h includes stdint.h so
any file that includes system.h will automatically have stdint.h
This is true for both files. limits.h on the other hand needs to
be explicitly included by whomever uses SIZE_MAX. This was already
done by source/fitz/store.c but not by source/fitz/memory.c, but
has now been added.
|
|
The lock checking functions are always enabled in debug mode, but
since they are not thread safe they may not be used in a
multi-threaded application. Multi-threaded applications are
required to set their own locking functions so the lock checking
functions should only be run if the default locking functions
are in use.
|
|
|
|
Currently, our API uses static inlines for fz_lock and
fz_unlock, the definitions for which depend on whether
we build NDEBUG or not. This isn't ideal as it causes
problems when people link a release binary with a debug
lib (or vice versa).
We really want to continue to use static inlines for the
locking functions as used from MuPDF, as we hit them
hard in the keep/drop functions.
We therefore remove fz_lock/fz_unlock from the public API
entirely. Accordingly, we move the fz_lock/fz_unlock
static inlines into fitz-imp.h (an internal header),
together with the fz_keep_.../fz_drop_... functions.
We then have public fz_lock/fz_unlock functions for any
external callers to use that are free of compilications.
At the same time, to avoid another indirection, we change
from holding the locking functions as a pointer to a
struct to a struct itself.
|
|
Don't mess with conditional compilation with LARGEFILE -- always expose
64-bit file offsets in our public API.
|
|
|
|
|
|
|
|
Don't use FMT_zu macro for fz_throw/fz_warn, since we can portably handle '%zu'
in our own printf formatting.
|
|
|
|
This silences the many warnings we get when building for x64
in windows.
This does not address any of the warnings we get in thirdparty
libraries - in particular harfbuzz. These look (at a quick
glance) harmless though.
|
|
This has knock on effects in the store.
fix
|
|
|
|
A few casts are required within the code, along with a few #ifdef
changes.
Some tweaks to curl are required too.
|
|
|
