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
This commit moves GStaticPrivate, g_thread_foreach and all
related functions and variables to gthread-deprecated.c. We
introduce some internal API to make this possible.
g_thread_foreach is not a very useful function, since there is
virtually nothing you can do with a GThread*, and implementing
it requires us to keep a list of threads around.
GStaticPrivate has been made redundant by adding comparable
capabilities to GPrivate.
https://bugzilla.gnome.org/show_bug.cgi?id=660635
Deprecate both g_thread_create functions and add
g_thread_new() and g_thread_new_full(). The new functions
expect a name for the thread.
Change GThreadPool, GMainContext and GDBus to create named threads.
https://bugzilla.gnome.org/show_bug.cgi?id=660635
