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
Compiling with `-Wfloat-conversion` warns about a few implicit
conversions from `double`/`float` to other numeric types in the `GValue`
transform functions.
These warnings are correct: value transformations can result in loss of
precision. That loss of precision is understood and expected, so add
some explicit casts to squash the warnings.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
Rather than defining it as a double constant. This introduces no
functional changes, but does squash some `-Wfloat-conversion` warnings.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
This makes no functional changes, but does avoid a warning from
`-Wfloat-conversion` due to implicitly switching from `guint64` to
`gdouble` and then back to `guint64`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
This avoids some false positive warnings from `-Wfloat-conversion`.
The code in `gtestutils.c` is a bit odd: it uses an array of `long
double` elements, with specific indices of that array storing specific
meaningful numbers, each of which has a type which is representable as a
`long double`, but which actually isn’t.
This is a prime candidate for refactoring to not use such a type-unsafe
API where everything is marshalled through `long double`. Unfortunately,
the array is declared in `GTestLogMsg`, which is defined in the public
`gtestutils.h` header, so we can’t change it. Boo.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
When building a typelib, the values of constants need to be converted
from a string format (from the GIR) to a binary format. This is
currently done, for all numeric types, using `g_ascii_strto*()`
functions, but with minimal validation. String values which are not
representable as binary numbers are either silently truncated or
clamped.
`-Wfloat-conversion` has flagged that this happens for floats – a
double-precision return from `g_ascii_strtod()` is implicitly cast down
to a float.
While we should ideally have some better error handling so that
conversion to a typelib fails if a constant is not representable in the
typelib, this is a problem for *all* numeric types and not just `float`,
so add an explicit cast to ignore the error for now.
In practice there probably isn’t a problem for any numeric types here,
as there should be validation of the string value when the GIR is
generated anyway.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
By keeping `expected` as a `double` for longer, we avoid having to cast
when populating the elements of `ordering`, to avoid
`-Wfloat-conversion` warnings.
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
As spotted by `-Wfloat-conversion`. Doubles which could not be
accurately represented as floats may have erroneously failed bounds
validation.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
libgirepository is not needed by most of the modules, but it is needed
by the `g-ir-scanner` generated dumper program. If we don’t explicitly
include the local version of it here, Meson will implicitly link against
it anyway, and that might pull in a different version, or try to link
against a half-built local version as the build ordering dependency tree
won’t reflect this relationship.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3401
Commit 9dad94e7q ensured `test_data` is freed when a test is skipped,
but didn't ensure that when a whole test suite is skipped.
We are assuming the ownership of `test_data` is passed to GTestCase
with `g_test_add_data_func_full()` so free `test_data` always when
freeing a test case.
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
gmacros.h casts functions to GDestroyNotify, which prevents enabling the
following hardening options in applications: -fsanitize=address
-fsanitize=cfi-icall (without -fsanitize-cfi-icall-generalize-pointers),
and -Wcast-function-type-strict.
Define another inline function that warps the original function into
GDestroyNotify.
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
When the file name is too long (for example, more than 238 bytes on
ext4), this will cause the creation of the .trashinfo file to fail.
Let's shorten the .trashinfo filename in this case, after all the
trash specification only requires unique filenames (see
`Contents of a trash directory` section in
https://specifications.freedesktop.org/trash-spec/trashspec-latest.html).
This should test the limits of loading 4GB files on i386 platforms, such
as the Hurd CI runner. On such platforms, `sizeof(size_t) == 4`.
This should fix the compiler warning from
https://gitlab.gnome.org/GNOME/glib/-/jobs/3989442:
```
../gio/tests/file.c:2931:51: error: left shift count >= width of type [-Werror=shift-count-overflow]
2931 | static const gsize testfile_4gb_size = ((gsize) 1 << 32) + (1 << 16); /* 4GB + a bit */
| ^~
cc1: all warnings being treated as errors
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
They take too long to include in a normal test run. They’ll still be run
in CI once a week as part of our scheduled slow test job.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The tests - one for sync, one for async - create a sparse file for
this purpose, so this should be cheap on the fileystem.
Of course, the test still allocates >4GB of memory for the data that it
returns from g_file_load_contents(), I hope the CI test runners can deal
with that.
GByteArray is limited to 4GB in size and the current code silently
overflows when that happens.
Replace both load_contents() and load_contents_async() implementations
with a version that uses realloc() and gsize to maintain the array.
The default values for construct properties always have to be set, even
if those properties are deprecated. The code to do that is in GLib, and
not under the control of the user (unless they completely override the
`constructor` vfunc, which is not recommended). So don’t emit a warning
for that if `G_ENABLE_DIAGNOSTICS` is enabled.
In particular, this fixes deprecation warnings being emitted for
properties of a parent class when chaining up with a custom constructor,
even when none of the child class code mentions the deprecated property.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3254
Disable tests that require update-desktop-database when it is missing.
It requires glib to build so it will be missing when bootstrapping glib.
Refactor the ifdef for Windows and MacOS while at it and reduce number
of ifdefs.
Ref: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3658
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
shared-mime-info required glib to build and will not be there during
bootstrap. Skip the test if it is missing.
ref: https://gitlab.gnome.org/GNOME/glib/-/issues/3317
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
Without the -Wno-typedef-redefinition option, clang complains if a typedef
gets redefined in gnu99 mode (since this is officially a C11 feature). This
also happened with old versions of GCC.
So, don't break the build on such warn, since we want to support
toolchains that supports C11 anyways.
We have required C99 for a while; in the meantime, most C toolchains
have moved on to C11 or later as the default C standard.
We still allow for C99 toolchains, but in the future we are going to
require a C11 toolchain to build and use GLib.
