The LibreOffice project builds Cairo with -DCAIRO_NO_MUTEX.
IMHO that's quite risky for big projects where you don't
control all the code that uses Cairo, but I assume they know
what they're doing.
This change should have been part of commit 87f7c60bf7, but
admittetly CAIRO_NO_MUTEX builds are not actively tested.
Fixes#921
lzo_uint is a typedef for a machine-sized unsigned integral.
We track sizes using unsigned long, which is machine-sized
on most (all?) Unices, but 32bit on 64bit Windows.
This means that lzo_uint and unsigned long are not really
interchangeable (should have used size_t!). Fix the build
by using intermediate variables. The cairo-script file format
ensures that uncompressed data fits within 4GB.
Fixes -Wincompatible-pointer-types errors.
Support for __uint128_t in CLangCL is currently broken [1].
Avoid using that type for now.
As of today MSVC doesn't support 128-bit integral types;
with this change we get feature-parity between MSVC and
CLangCL, so this shouldn't be a problem.
References:
* Clang-cl generates a call to an undefined symbol __udivti3
https://github.com/llvm/llvm-project/issues/25679
"Placeholder" scaled fonts created temporarily by cairo-user-font.c never
get to have an original_font_face (that is, it's always NULL). This breaks
the font-map mapping. Also check the implementation font-face.
Fixes#876
It's possible for a pool allocation to fail under glitter_scan_converter_add_edge,
in which case longjmp will be called to bail out, but the converter's jmp_buf
hasn't been appropriately initialized to catch the error.
Make sure surface->object_stream.stream is cleaned up even if things
failed
In poppler oss-fuzz tests we are getting this leak reported
Direct leak of 64 byte(s) in 1 object(s) allocated from:
#0 0x5747417eabd9 in __interceptor_calloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:74:3
#1 0x574742706f5b in _cairo_memory_stream_create cairo/src/cairo-output-stream.c:741:14
#2 0x5747426757b8 in _cairo_pdf_surface_open_object_stream cairo/src/cairo-pdf-surface.c:2307:34
#3 0x57474266b880 in _cairo_pdf_surface_finish cairo/src/cairo-pdf-surface.c:2700:14
#4 0x57474261afc6 in _cairo_surface_finish cairo/src/cairo-surface.c:1043:11
#5 0x57474261afc6 in cairo_surface_finish cairo/src/cairo-surface.c:1092:5
#6 0x57474270808a in _cairo_paginated_surface_finish cairo/src/cairo-paginated-surface.c:215:2
#7 0x5747426175c2 in _cairo_surface_finish cairo/src/cairo-surface.c:1043:11
#8 0x5747426175c2 in cairo_surface_destroy cairo/src/cairo-surface.c:978:2
This fixes it.
_cairo_pdf_surface_finish was succeeding past
_cairo_pdf_surface_open_object_stream that allocates surface->object_stream.stream,
failing when calling _cairo_pdf_surface_emit_font_subsets
and that memory was never freed
Otherwise gitlab-runner prints a few warnings:
> Uploading artifacts...
> WARNING: Part of .git directory is on the list of files to archive
> WARNING: This may introduce unexpected problems
Both system() and popen() invoke the shell. Which shell is
invoked depends on the COMSPEC environment variable, but
usually it's CMD.exe.
CMD.exe doesn't quite like paths with forward slashes in its
command-line. Most of the times, the forward slash is mistaken
for a command line switch (the start of an option). For example:
cmd /c "dir C:\Windows" works
cmd /c "dir C:/Windows" doesn't work
Open the pipe in binary mode on Windows to get the expected
byte counts. Note that the 'b' mode for popen is not portable
and so is used only on Windows:
> The behavior of popen() is specified for values of mode of "r",
> "w", "re", and "we". Other modes such as "rb" and "wb" might be
> supported by specific implementations, but these would not be
> portable features.
https://pubs.opengroup.org/onlinepubs/9799919799/functions/popen.html
We now require at least Windows Vista. When dwrite is disabled, declare
WINVER accordingly so we get the defines we no longer carry ourselves.
The default dwrite-enabled path already has a new-enough WINVER.
Fixes: d0ee67a142 ("Win32: Remove unused code and defines for old toolchains")
