Make sure that it calls absolutely nothing that may ever recurse back
into GLib again:
- g_ascii_strcasecmp() is unsafe because it has g_return_if_fail() at
the top. As far as I know, the only ASCII character letter that
would get special treatment here is "i" and that appears in neither
"help" nor "all".
- g_getenv() is very complicated on Windows, so use a simple version
that is sufficient for our purposes.
Now that it's completely safe, we can just call it from g_logv() in the
usual way without all of the hacks.
https://bugzilla.gnome.org/show_bug.cgi?id=660744
Add _g_io_module_get_default(), which implements the
figure-out-the-best-available-module-that-is-actually-usable logic,
and use that to simplify g_proxy_resolver_get_default(),
g_settings_backend_get_default(), g_tls_backend_get_default(), and
g_vfs_get_default().
https://bugzilla.gnome.org/show_bug.cgi?id=620932
g_file_make_directory_with_parents() will fail for already
existing directories, unlike g_mkdir_with_parents(), so mention
this clearly in the docs.
https://bugzilla.gnome.org/show_bug.cgi?id=660791
The GIOScheduler was using a GCond in a way that didn't deal with the
possibility of spurious wakeups. Add an explicit predicate and a loop.
Problem caught by Matthias Clasen.
https://bugzilla.gnome.org/show_bug.cgi?id=660739
Give the macro wrapper treatment to g_once_init_enter() and leave() in
the same style that we did for gatomic.
It is now possible to use these macros with any pointer-sized object,
and not just gsize. The leave() macro ensures that the initialisation
result is a compatible type with the pointer that it is being written
to.
Just like with gatomic, there could be problems caused by use of (void*)
casts. We'll see how that goes, and reevaluate if necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=660743
On OpenBSD translation files are always installed under PREFIX/share/locale,
there is no such thing as PREFIX/lib/locale; according to that, set
DATADIRNAME to "share".
Presumably, the rationale for not storing the endianness is that
GVariant is a recursive type system, and in a sane format, endianness
only needs to be stored once per blob of data (once per D-Bus message,
once per file on disk, etc.).
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=632049
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ryan Lortie <desrt@desrt.ca>
Also include a shorter version in the docs for g_variant_store, with a
pointer to g_variant_get_data.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=632049
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ryan Lortie <desrt@desrt.ca>
Strings matching /%[a-z]/ are special syntax for gtk-doc.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=632049
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ryan Lortie <desrt@desrt.ca>
This covers the str, double, int, int64 hash and equal functions, but not
anything that takes an "object", since the convention is that "object
methods" never accept NULL anyway.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=592715
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
Also annotate them as (allow-none), more for the benefit of gtk-doc
readers than introspection.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=592715
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
Using g_int_hash, g_int_equal with keys like GINT_TO_POINTER (n) seems to
be a reasonably common GLib-novice mistake. It doesn't help that the
documentation for GHashFunc was ambiguous about this.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=592715
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
It's impossible to check this if the library user is using
g_type_register_static, but in that case their compiler should hopefully
warn about the truncation. This fixes it for G_DEFINE_TYPE and friends,
at least.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=659916
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
The copying of code from g_async_queue_new() to g_async_queue_new_full()
in ef08aa786b copied the setting of the
free function to NULL (instead of the one passed in by the user).
Fix that up so that the test passes again.
https://bugzilla.gnome.org/show_bug.cgi?id=660843
Make the options from an /etc/fstab entry available as public API -
this can be used to support options such as
comment=gvfs.name=Foo\040Bar
to e.g. set the name of an fstab mount in the UI to "Foo Bar".
https://bugzilla.gnome.org/show_bug.cgi?id=660536
Signed-off-by: David Zeuthen <davidz@redhat.com>
This reverts commit c841c2ce3f.
This approach has been an unmitigated disaster. We're getting all sorts
of crashes due to functions that are returning NULL because they can't
find the schema for the default value. The people who get these crashes
are then confused about the root cause of the problem and waste a lot of
time trying to figure it out.
Until we find a better solution, we should go back to what we had
before.
https://bugzilla.gnome.org/show_bug.cgi?id=655366
The markup here was not only broken, it was also unnecessary,
since gtk-doc knows to apply <function></function> tags to things
that end with () already.
Add a little bit more room in the ABI for our synchronisation primatives
since we're going to need it when we add native implementations on
Linux.
Also: rename the pointer field and add /*< private >*/ annotations.
All locks are now zero-initialised, so we can drop the G_*_INIT macros
for them.
Adjust various users around GLib accordingly and change the docs.
https://bugzilla.gnome.org/show_bug.cgi?id=659866
Modify the POSIX implementation of the synchronisation primatives to use
the same ABI as Windows: one pointer for each type.
This frees us from having to #include <pthread.h> and avoids the problem
with pthread_rwlock_t not being defined under certain compiler defines.
A few more changes are expected to the ABI -- they will be committed
separately.
https://bugzilla.gnome.org/show_bug.cgi?id=659866
