It incorrectly said that an error could only be returned if the GVariant
was incorrect for the D-Bus API, but that’s not true: an error will also
be returned if you call it on a closed GDBusConnection.
Clarify that, and mention the actual error codes which are returned.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
The return value of the g_hash_table_add(), g_hash_table_insert(), and
g_hash_table_replace() functions was changed from void to gboolean in
GLib 2.40, but it was not mentioned in the API reference or the release
notes.
https://bugzilla.gnome.org/show_bug.cgi?id=793300
If calling g_subprocess_communicate() on a GSubprocess with no
stdout/stderr pipe, a critical warning would be emitted from
g_memory_output_stream_steal_as_bytes(), as it would be called on a NULL
output stream.
Fix that, improve the relevant GIR annotations, and expand the unit
tests to cover it (and various other combinations of flags).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793331
The test_GDateTime_new_from_unix() test creates a UNIX timestamp
representing 1990-01-01 00:00:00 in the local timezone, and then turns
it into a GDateTime using g_date_time_new_from_unix_local(). This should
succeed regardless of the current local timezone (TZ environment
variable).
However, it was failing for TZ=America/Lima, and *only* for that
timezone.
As it turns out, Lima used to have a DST leap at exactly 00:00:00 on the
1st of January — but this stopped in 1994, which made investigation a
bit harder. See:
https://www.timeanddate.com/time/change/peru/lima?year=1990.
What was happening is that 1990-01-01 00:00:00 was being converted to
the timestamp 631170000, but GDateTime was converting that timestamp to
1990-01-01 01:00:00 when loading it. Both conversions are correct: a DST
leap creates an equivalence between an hour’s worth of timestamps.
We can somewhat validate this by seeing that timestamp 631169999 maps to
1989-12-31 23:59:59, and timestamp 631170001 maps to 1990-01-01
01:00:01.
Fix this by changing the date used by the test to one where no timezone
was undergoing a DST leap in 1990. This should never change, as all that
data is now historical.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793319
Since commit 96ebcee8c4, we don’t actually need libmount 2.28. Lower our
dependency to 2.23 so that we can continue to build against CentOS 7.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: Emmanuele Bassi <ebassi@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=793288
Building against libmount installed into a non-default prefix wasn’t
working, as we were using #include <libmount/libmount.h> rather than
the correct #include <libmount.h> — all the mount.pc pkg-config files
set `Cflags: -I${includedir}/libmount`.
Fixing this while retaining the fallback support for versions of
libmount without a pkg-config file would have been tricky (we would need
to work out a suitable -I flag to set in LIBMOUNT_CFLAGS) to still be
able to use the correct #include path). Thankfully, libmount gained
pkg-config support a long time ago, so I think we can safely drop the
fallback code. In particular, Debian Jessie, Ubuntu Trusty, and CentOS 5
all ship a mount.pc file.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793288
If flush_async is deleted by a child class, then calling
g_output_stream_flush_async would leave the GOutputStream in an invalid
state. I'm not aware of any GOutputStream that would be affected by this
issue, but might as well fix it.
https://bugzilla.gnome.org/show_bug.cgi?id=738277
The existing array annotation is inconsistent with the other
conversion functions. Now that the implementation guarantees
no embedded NULs, the return value can be re-annotated.
https://bugzilla.gnome.org/show_bug.cgi?id=756128
Note that the g_convert() API works with byte arrays. It's wrong to
default to utf8 there, because iconv can read and produce strings with
interior nul characters which are not allowed in (type utf8).
The documentation was misleading about that in some places, so that got
corrected as well.
Strings in the locale encoding are annotated as dynamic-length byte
arrays because they don't have any guaranteed format and can contain
nul bytes. For UTF-8 strings in g_*_{from,to}_utf8(), GLib assumes
no embedded nul bytes and the (type utf8) annotations on the UTF-8
parameters and return values remain as they were. Likewise for
(type filename).
https://bugzilla.gnome.org/show_bug.cgi?id=756128
It's not possible to subclass GValue, and by always explicitly casting
here it is easy to write broken code (e.g. passing a GValue**) without
the compiler warning about that.
By not casting, the compiler will error out if anything but a GValue* is
passed here.
https://bugzilla.gnome.org/show_bug.cgi?id=793186
Introduced in commit 1574321e51.
This fix introduces no functional changes (just a cast).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
g_variant_get_objpathv() doesn’t exist. The code actually meant
g_variant_get_objv().
This fixes a leak with `ao`-type properties in generated code.
Previously they wouldn’t be freed; now the container is (correctly)
freed.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=770335
This seems to have been present since the code was introduced in commit
cedc82290f. The attr variable is defined
under one #ifdef, but destroyed under another, which doesn’t make any
sense. The second #ifdef variable is actually an enum value, rather than
the static initialiser value which makes more sense in the context.
Note that GMutex used to be statically initialised to the value of
PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP in gthread.h, before this was
reworked in commit e081eadda5.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793026
g_key_file_get_locale_string() returns a translated string from the
keyfile. In some cases, it may be useful to know the locale that that
string came from.
Add a new API, g_key_file_get_locale_for_key(), that returns the locale
of the string.
Include tests.
(Modified by Philip Withnall to rename the API and fix some minor review
issues. Squash in a separate test case commit.)
https://bugzilla.gnome.org/show_bug.cgi?id=605700
res_query() uses global state in the form of the struct __res_state
which contains the contents of resolv.conf (and other things). On Linux,
this state seems to be thread-local, so there is no problem. On OS X,
however, it is not, and hence multiple res_query() calls from parallel
threads will compete and return bogus results.
The fix for this is to use res_nquery(), introduced in BIND 8.2, which
takes an explicit state argument. This allows us to manually store the
state thread-locally. If res_nquery() isn’t available, we fall back to
res_query(). It should be available on OS X though. As a data point,
it’s available on Fedora 27.
There’s a slight complication in the fact that OS X requires the state
to be freed using res_ndestroy() rather than res_nclose(). Linux uses
res_nclose().
(See, for example, the NetBSD man page:
https://www.unix.com/man-page/netbsd/3/res_ninit/. The Linux one is
incomplete and not so useful:
http://man7.org/linux/man-pages/man3/resolver.3.html.)
The new code will call res_ninit() once per res_nquery() task. This is
not optimal, but no worse than before — since res_query() was being
called in a worker thread, on Linux, it would implicitly initialise the
thread-local struct __res_state when it was called. We’ve essentially
just made that explicit. In practical terms, this means a
stat("/etc/resolv.conf") call per res_nquery() task.
In future, we could improve this by using an explicit thread pool with
some manually-created worker threads, each of which initialises a struct
__res_state on spawning, and only updates it on receiving
the #GResolver::reload signal.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=792050
Some projects use child schemas in an odd way: they link children which
already have their path pre-defined. This causes the child schema (and
its keys) to be printed out twice:
- once because it is, itself, a non-relocatable schema
- once, as a recursion from its parent
We can avoid this by not recursing into child schemas that are
non-relocatable (on the assumption that they will be enumerated
elsewhere).
https://bugzilla.gnome.org/show_bug.cgi?id=723003
When compiling with G_LOG_USE_STRUCTURED, g_message(), g_debug(), etc.
use g_log_structured(). The message format string and its format
arguments are passed as the final set of arguments in a longer varargs
list, which includes the log domain and level (and other) fields.
Passing the message format in this way means it’s not possible for the
compiler to know to check its format placeholders when compiling with
-Wformat.
Fix support for this by adding a new semi-private helper function,
_g_log_structured_standard(), which only uses varargs for the message
format and its arguments, and uses fixed arguments for the other fields.
This is then converted to a set of GLogFields and passed to
g_log_structured() as normal.
Support for -Wformat when compiling *without* G_LOG_USE_STRUCTURED was
never broken.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793074
g_data_input_stream_read_upto() was introduced in 2.26; now it’s GLib
2.56, we can probably deprecate the old versions (since the handling of
consuming the stop character differs between the sync and async versions
of it).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=584284
The behaviour of upstream iconv() when faced with a character which is
valid in the input encoding, but not representable in the output
encoding, is implementation defined:
http://pubs.opengroup.org/onlinepubs/9699919799/
Specifically:
If iconv() encounters a character in the input buffer that is valid,
but for which an identical character does not exist in the target
codeset, iconv() shall perform an implementation-defined conversion
on this character.
This behaviour was being exposed in our g_iconv() wrapper and also in
g_convert_with_iconv() — but users of g_convert_with_iconv() (both the
GLib unit tests, and the implementation of g_convert_with_fallback())
were assuming that iconv() would return EILSEQ if faced with an
unrepresentable character.
On platforms like NetBSD, this is not the case: NetBSD’s iconv()
finishes the conversion successfully, and outputs a string containing
replacement characters. It signals those replacements in its return
value from iconv(), which is positive (specifically, non-zero) in such a
case.
Let’s codify the existing assumed behaviour of g_convert_with_iconv(),
documenting that it will return G_CONVERT_ERROR_INVALID_SEQUENCE if
faced with an unrepresentable character. As g_iconv() is a thin wrapper
around iconv(), leave the behaviour there implementation-defined (but
document it as such).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790698
Fix capitalisation of GLib, make some text less gender-specific, and add
some missing colons.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790698
off64_t doesn’t exist in any standard (definitely not C99), and so
goffset is actually closer to off_t in 64-bit mode.
However, goffset is always defined as gint64, so make that clear.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=792856
