These are all fairly straightforward, but I didn’t get them locally;
they only showed up on CI.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
Fixing #3405 is going to take a lot of work, so let’s split it up into
pieces and work on them separately. The `gobject/` and `gobject/tests/`
directories now compile cleanly with `-Wsign-conversion` (see the
previous commits), so let’s enable the warning for those directories to
prevent regressions while we continue to work on the other directories.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
There’s a painful inconsistency in the types of the
`g_{test_rand,random,rand}_int{,_range}()` functions, which vary
arbitrarily between `gint32` and `guint32`.
Unfortunately since those functions mention `int` explicitly in the name
(and then some of them return an `unsigned` integer), I don’t see a way
to make the APIs consistent without significant deprecations or
additions.
So, for the moment, to fix various `-Wsign-conversion` warnings, plaster
the tests with casts.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
This fixes a load of -Wsign-conversion warnings. The dest type setter
function is being used (presumably by design?) so there’s sometimes a
type mismatch (signed/unsigned, or size) with the constant value being
used by the test. This just makes the existing implicit casts explicit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
Fix all the instances where `-Wsign-conversion` was pointing out that
`g_assert_cmpint()` had been used on unsigned inputs, or vice-versa.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
Not sure why these constants were chosen the way they were, but that’s
not a problem I’m going to investigate right now. This just makes the
implicit cast explicit to shut the compiler warning up.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
This fixes `-Wsign-conversion` warnings, though I’m not sure why the
compiler is emitting them. The signed/unsigned status of flag enum
members is not particularly well defined in the C standard (and even
less well understood by me), so just do what seems necessary to shut the
compiler up.
The benefits of enabling `-Wsign-conversion` across the codebase
hopefully outweighs this noise.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
While we’re at it, rename the variables to make the intent a bit
clearer: these functions return a boolean indicating whether any of the
values were modified to make them valid. `n_changed` is a counter of the
number of modified values.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
Unfortunately the signatures of our atomic functions alternate between
using signed and unsigned integers across different functions, so we
can’t just use one type as input. Add some explicit casts to fix
harmless `-Wsign-conversion` warnings.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
Rather than reinventing it ourselves. The old version in `gboxed.c`
could lose the second half of very long strings, as it truncated the
`size_t` string length to the `ssize_t` accepted by
`g_string_new_len()`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
This does a deep copy on the `GString`.
It means we can eliminate the less-efficient version currently used for
`GBoxed`, which also has `-Wsign-conversion` problems. See the following
commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
Add an internal helper for `g_checksum_update()` to avoid having to take
its length as a `gssize` for internal users who already know the input
length.
Fixes a `-Wsign-conversion` warning.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
The code wasn’t written for it, and we don’t want to diverge from
upstream for this, so disable -Wsign-conversion in case it was set for
the overall GLib build.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
The parser was assuming that all three separators (`_@.`) were in order;
but the input might not contain them in order. In that case, the parser
would have passed negative values to `g_strndup()` which would have been
implicitly cast to large positive values, and potentially exposed a lot
of memory (until the first nul byte, which was probably quite soon).
Expand the existing `g_get_locale_variants()` test to cover some invalid
parsing, and add a fuzzing test too.
Spotted by `-Wsign-conversion`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
It's expected that an interface may have a NULL socket address, so just
skip it and don't crash if so. In practice, this occurs for VPN
interfaces.
Fixes: fe0139ee98
Thankfully this struct is also internal, so we can happily change the
types of any field except the first one (which is in the public `GTuples`
prefix).
This fixes the remaining `-Wsign-conversion` warnings for `grel.c`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
`GTuples.len` is a `guint`.
This doesn’t seem to have caused any problems or warnings, but let’s get
it correct.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
We would otherwise have to have cast and lost width and signedness on
both the arguments to, and return value from, `g_relation_count()`.
Simpler to add an internal helper with the right types, and only do the
casts on the public API wrapper where API stability means it’s
unavoidable.
Fixes some more `-Wsign-conversion` warnings.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
Previously this was passed straight into an array dereference, so could
easily have under- or over-flowed the array.
Add a precondition check to it. This doesn’t change the API contract,
because the code already emitted a critical warning if the index didn’t
find a table:
```
g_return_val_if_fail (table != NULL, NULL)
```
This fixes a load of `-Wsign-conversion` warnings and makes these
functions safer.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
This is what’s documented as supported (and the only value that is
supported), so might as well check for it early.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The internals of this struct are private, so we have some freedom to fix
the types used to be wider (to allow addressing all of memory) and
correctly unsigned.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
The code wasn’t written for it, and we don’t want to diverge from
upstream for this, so disable -Wsign-conversion in case it was set for
the overall GLib build.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
Wherever we use gssize to allow passing -1, we need to ensure we don't
overflow the value by assigning a gsize to it without checking if the
size exceeds the maximum gssize. The safest way to do this is to just
use normal gsize everywhere instead and use gssize only for the
parameter.
Our computers don't have enough RAM to write tests for this. I tried
forcing string->len to high values for test purposes, but this isn't
valid and will just cause out of bounds reads/writes due to
string->allocated_len being unexpectedly small, so I don't think we can
test this easily.
Make it a bit clearer that a returned `GFileInfo` can be empty if
`stat()` fails (e.g. with `EACCES`), and that it’s the caller’s
responsibility to use `g_file_info_has_attribute()` before retrieving
attribute values.
This better documents what we implemented in, for example, !3336.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3658
It probably would get inlined anyway(?). But add G_ALWAYS_INLINE
to be more sure about this. We don't want this mostly trivial
function to be a separate call.
These are similar to g_pointer_bit_lock_and_get() and
g_pointer_bit_unlock_and_set().
The bitlock API is pretty amazing, as it allows to use a single bit of
an integer for locking while using the remaining 31 bits for other
purposes. But those other bits always need to be accessed atomically
too.
There is a use in being able to lock_and_get(), to combine the setting
of the lock bit and fetching the new value at once. For one, that can
safe additional atomic operations to fetch the value afterwards. But
more importantly, it allows to do this change in one atomic operation.
Likewise, unlock_and_set() allows to atomically clear the lock bit and
set a new value (while also preserving unrelated bits, by using the
@preserve_mask parameter).
