That leads to compilation errors with CLang (depending
on the order of includes):
> In file included from ../test/invalid-matrix.c:31:
> In file included from /usr/include/fenv.h:64:
> /usr/include/bits/fenv.h:26:5: error: expected identifier
> 26 | FE_INVALID =
> | ^
> ../test/cairo-test.h:78:20: note: expanded from macro 'FE_INVALID'
> 78 | #define FE_INVALID 0
> | ^
Instead of defining standard macros, rely on the value of
(math_errhandling & MATH_ERREXCEPT) to check if floating-point
exceptions are supported. If so, all three macros FE_DIVBYZERO,
FE_INVALID, and FE_OVERFLOW are guaranteed to be defined.
https://en.cppreference.com/w/c/numeric/math/math_errhandling.html
On Windows SDK <= 10.0.22621.0 (as we currently have in CI),
INFINITY is defined as a compound expression that overflows
at runtime.
From Windows SDK 10.0.26100.0 onwards, INFINITY is defined
as a literal expression (double) cast'ed to float. That
doesn't trigger the overflow at runtime. The previous behavior
can be retained by defining _UCRT_LEGACY_INFINITY.
The Win32 boilerplated works by positioning a test HWND
at (INT_MIN, INT_MIN) and drawing into the client HDC.
However, the image read-back always yields a blank image
(_cairo_boilerplate_get_image_surface).
The window is positioned offscreen, thus GDI returns an
HDC that is completely clipped, as GDI always clips to
the visible region of the client area. In short, every
drawing operation turns into a no-op.
It's probably best to use a bitmap target with a memory
DC. This commit reworks the Win32 boilerplate to target
a DIB section.
Both system() and popen() invoke the command interpreter;
that's CMD.exe on Windows (or whatever is specified in the
COMSPEC environment variable).
The Windows API supports forward slashes in paths just fine,
but CMD doesn't (well, it does in very specific cases [1]).
Forward slashes are always parsed as start of switches / options.
[1] https://devblogs.microsoft.com/oldnewthing/20180605-00/?p=98915
Avoids a translation from LF to CRLF, which messes up the
expected byte counts.
Note that popen() on GLibc does not support the 'b' mode,
so this change is for Windows only. From the POSIX.2024
spec:
> 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.
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")
This happens when converting _cairo_status to _cairo_int_status:
warning C5286: implicit conversion from enum type '_cairo_int_status' to
enum type '_cairo_status'; use an explicit cast to silence this warning
They don't support C11 anyway. Additionally, CLang defines a very
conservative __GNUC__ value (which is also configurable via the
-fgnuc-version= command-line argument)
When cairo_is_all_clipped return true, we must not attempt
to change any of the clip fields, since it is pointing to
the static const __cairo_clip_all.
Moving the check for ->region into the 'if' is fine, since
it will always be NULL for _cairo_clip_all.
This was causing a crash in inkscape, see
https://gitlab.com/inkscape/inkscape/-/issues/5631
