fb58d55187 added weak linking for ASAN,
skipping it for MinGW because weak symbols are broken there.
The same is true for Cygwin, so skip things there too.
This fixes the following build error under MSYS2:
/usr/lib/gcc/x86_64-pc-msys/13.3.0/../../../../x86_64-pc-msys/bin/ld:
glib/msys-glib-2.0-0.dll.p/gutils.c.o:gutils.c:
(.rdata$.refptr.__lsan_enable[.refptr.__lsan_enable]+0x0): undefined reference to `__lsan_enable'
On Linux the error will be `G_IO_ERROR_CONNECTION_REFUSED`, but on macOS
it will be `G_IO_ERROR_TIMED_OUT`. Both errors seem reasonable to me, so
let’s not specifically require one of them.
See: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4104#note_2161451
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
There are a couple of places in the code which use `isnan()` and have
platform-specific workarounds for it. Unify those, and extend the
workaround to work for msys2-mingw32.
It seems that msys2-mingw32 can’t automatically use `isnan()` in a wider
mode than `float`:
```
In file included from ../glib/gdatetime.c:60:
../glib/gdatetime.c: In function 'g_date_time_new':
../glib/gdatetime.c:1648:14: error: conversion from 'gdouble' {aka 'double'} to 'float' may change value [-Werror=float-conversion]
1648 | isnan (seconds) ||
| ^~~~~~~
cc1.exe: all warnings being treated as errors
```
See: https://gitlab.gnome.org/pwithnall/glib/-/jobs/4022715
Using it in float mode on all platforms should not change behaviour, as
a conversion from `(double) NAN` to `float` should still give `NAN`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
This should have been dropped in commit
38faeca62e but somehow that didn’t happen
and somehow it wasn’t caught by the CI until afterwards.
Fixes: https://gitlab.gnome.org/GNOME/glib/-/jobs/4049254
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
For each test expected to return valid DNS records, test that the
record variants are not floating references.
Also add an test which checks this explicitly for a simple TXT record.
The return value to `lookup_records()` methods is set as `transfer full`
but the code path in `g_resolver_records_from_res_query()` doesn't
sink the GVariant.
Add the `g_variant_ref_sink()` call when prepending the record, so
the list hold a full reference on each records.
closes#3393
It’s deprecated, but I was modifying it anyway and it didn’t have any
coverage, so let’s add a simple test (as suggested by Michael
Catanzaro).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
- Add licensing tags
- Tweak spacing, colors, line thicknesses
- Create light-mode version
- Use `<picture>` tag to include appropriate version for each media
color scheme.
Recreate the `menu-model.png` diagram in SVG, with box outlines and
connectors recolored from black to white. This will allow the diagram
to show up better in the dark documentation theme.
gnulib doesn’t work with it, and if we try and enable it then mingw
versions of `signbit()` start causing problems.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
While an index greater than `G_MAXINT` can’t be passed to
`g_ptr_array_insert()`, `-1` can be — and if that’s done with an array
which has more than `G_MAXINT` elements in it, the new element will be
inserted part-way through the array rather than being appended.
Spotted by building with `-Wsign-conversion`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
The latter only accepts a `gint` as the number of elements in the array,
which means that its use in `GArray` (and related array implementations)
truncates at least half the potential array size.
So, introduce a replacement for it which uses `size_t` for the number of
elements. This is inline with what `qsort()` (or `qsort_r()`) actually
does. Unfortunately we can’t directly use `qsort_r()` because it’s not
guaranteed to be a stable sort.
This fixes some `-Wsign-conversion` warnings (when building GLib with
that enabled).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
GLib now compiles without emitting any float conversion warnings, so
let’s keep it that way.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
If we enable `-Wfloat-conversion`, these warn about a possible loss of
precision due to an implicit conversion from `double` to some other
numeric type.
The warning is correct: there is a possible loss of precision here. In
these instances, we don’t care, as the floating point arithmetic is
being done to do some imprecise scaling or imprecise timing. A loss of
precision is not a problem.
So, add an explicit cast to squash the warning.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
The tests were using a lot of signed `int`s when actually the values
being handled were always non-negative. Use `unsigned int` consistently
throughout.
Take the opportunity to move declarations of loop iterator variables
into the loops.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
There were various places where (signed or unsigned) integer assertions
were being used to compare `double` or `float` values, resulting in an
implicit integer conversion.
This causes a warning when building with `-Wfloat-conversion`.
Improve the specificity of the tests by using the most-specific numeric
assertions through all `param` tests.
For the conversion tests, this means using the assertion function
associated with the target type, not the source type.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
