| Age | Commit message (Collapse) | Author |
|---|
|
Use android logging for throw/warn like we do with OutputDebugString
on windows.
|
|
Don't mess with conditional compilation with LARGEFILE -- always expose
64-bit file offsets in our public API.
|
|
|
|
|
|
Keeping them up to date is difficult and prone to errors, so we move
setting the USE_OUTPUT_DEBUG_STRING and FZ_LARGEFILE flags to the source
instead of relying on project file definitions.
|
|
This makes debugging much simpler.
|
|
Fix for bug 696913.
|
|
|
|
|
|
|
|
|
|
In the current code, when we hit the fz_try(), we check to see
if we are about to overflow the exception stack. If we are,
we throw. This does NOT throw to the fz_catch following the
try, but rather to the enclosing fz_always/fz_catch blocks.
This can cause leaks, as it's very hard to code correctly.
It would be a far nicer behaviour to have a failure in fz_try()
cause us to throw to the immediately following fz_always/fz_catch.
This commit achieves that.
|
|
We compile with -Wno-unused-parameters instead.
|
|
Use a pointer to the top error stack slot instead of access via
array and index. Return the stack slot from fz_push_try.
|
|
|
|
Tor turned up an interesting section in the C spec about this. See
page 275 of http://open-std.org/jtc1/sc22/wg14/www/docs/n1494.pdf
regarding acceptable places for setjmp to occur.
It seems that:
if (setjmp(buf))
if (!setjmp(buf))
if (setjmp(buf) {==,!=,<,>} <integer constant>)
etc are all valid things to do, but assignments (and subsequent
testing of values) like:
if ((code = setjmp(buf)) == 0)
are not allowed.
Further, it's not even clear that:
if (a() && setjmp(buf))
is permissible.
We therefore recast the macros into the form:
a();
if (setjmp((buf)) == 0)
which should be acceptable under the C spec.
To keep try atomic, we introduce a block '{{{' around this, along
with a matching close block '}}}' in the catch clause. This has the
nifty extra effect of giving us a compile time error if we mismatch
our try/catches.
|
|
Add a new class of errors and use them to abort interpretation when
the test device detects a color page.
|
|
We build MuPDF without NDEBUG defined in order to check assertions but
don't want Visual Studio's Output console flooded with warnings for
broken documents. So instead of always defining USE_OUTPUT_DEBUG_STRING
for debug builds under Windows, allow the VS solutions to define it
when desired and to omit it when not.
|
|
|
|
We are testing this using a new -p flag to mupdf that sets a bitrate at
which data will appear to arrive progressively as time goes on. For
example:
mupdf -p 102400 pdf_reference17.pdf
Details of the scheme used here are presented in docs/progressive.txt
|
|
Stupid windows debugger doesn't show stdout/stderr anywhere in
non console apps, so add code to make errors/warnings visible.
|
|
We need to have it as a prefix, not a postfix now, but it should
work on both gcc and MSVC now.
|
|
|
