Unlike, say, g_variant_new(), which returns a floating reference.
g_variant_parse() returns a non-floating one, so must always have
g_variant_unref() called on the result.
Our signal handler calls write() on a pipe or an eventfd in order to
deliver the notification. It's unlikely, but this could fail, setting
errno. We even check the case that it fails with EINTR.
If it does set errno, then it has potentially blown away the value or
errno that the preempted code cared about (ie: if the signal arrived
shortly after a system call but before errno was checked).
Wrap the handler with code to save errno.
https://bugzilla.gnome.org/show_bug.cgi?id=741791
Fix a few typical problems, and also stop wrapping the inline definition
of g_steal_pointer in parens, since it is not necessary and it confuses
gtk-doc.
It was added after G_END_DECLS, outside the #ifdef G_PLATFORM_WIN32,
and inside a #ifndef __GTK_DOC_IGNORE__ block. So it was missing from
the doc.
https://bugzilla.gnome.org/show_bug.cgi?id=743661
• Clarify that GError** parameters are for the return of _newly
allocated_ GError*s.
• Clarify that errors may need to be checked for explicitly if the
return value of a function doesn’t reliably indicate them.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
i.e. That calling g_timeout_add() from a thread other than the main one
probably doesn’t do what you want. Same for g_idle_add() and the
*_full() variants.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
It was documented before, but wasn’t especially clear. Doing
if (X)
g_free (X);
is apparently quite a pervasive real-world anti-pattern, so perhaps it
could be documented more explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
Just in case people have forgotten their basic algorithms course. Seen
in some pretty terrible code in the wild; hopefully mentioning the cost
in the documentation will make people think twice about using a counter
variable when iterating over a linked list.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
It’s NULL iff free_segment is TRUE, so the annotation doesn’t quite
capture all the function definition, but is a safe over-estimate of the
return value’s nullability.
https://bugzilla.gnome.org/show_bug.cgi?id=719966
I love Emacs keyboard macros, used them to convert the list of
defines cleverly into a list of tests, then iterated and filled in
the necessary constructor arguments.
- It's not sufficient, there are other bare array types
like guint8, gdouble, etc.
- Other types like GVariant* always come as pointers, whereas
there's a rather fundamental distinction between "gchar" and
"gchar*" that has been signified to C programmers for 30+ years via
the '*' character, and we're hiding that.
https://bugzilla.gnome.org/show_bug.cgi?id=744747
The g_autoptr() being associated with the type name works out really
well for things like GHashTable. However, it's a bit more awkward to
associate with "gchar". Also because one can't use "char".
Similarly, there are a lot of other "bare primitive array" types that
one might reasonably use.
This patch does not remove the autoptr for "gchar", even though I
think it's rather awkward and strange.
Also while we're here, add a test case for the cleanup bits.
https://bugzilla.gnome.org/show_bug.cgi?id=744747
This would allow bindings to use _get_option_group() functions, which
would then allow them to use GOption parsing.
This also adds introspection annotations to
g_option_context_add_group(), g_option_context_set_main_group() and
g_option_context_get_main_group().
https://bugzilla.gnome.org/show_bug.cgi?id=743349
Despite linked lists being a fairly fundamental computer science
concept, some developers insist on using:
g_list_length (list) > 0
to determine whether a list is non-empty, rather than using:
list != NULL
Add a comment to the documentation for g_list_length() and
g_slist_length() pointing out the better alternative in the hope that it
will prevent some of this abuse.
https://bugzilla.gnome.org/show_bug.cgi?id=741024
gmem.h and gthread.h made use of the inline keyword, that is not available
on all compilers in C-mode, causing builds to break on such compilers.
Include glib/gutils.h which handles the inline issue, in place of
glib/gtypes.h if applicable, which is included quite early on by
glib/gutils.h.
https://bugzilla.gnome.org/show_bug.cgi?id=744190
We have a test that #includes our headers from a C++ program to make
sure we don't throw any errors or warnings as a result of that.
The new inline implementation of g_steal_pointer() does an implicit
conversion from (void *), which is not valid in C++.
Add a cast to avoid the problem.
Thanks to Ignacio Casal Quinteiro for the report.
This is particularly nice when used with g_autoptr(). See examples in
the docs.
This patch is based upon an idea (and original patch submission) from
Will Manley <will@williammanley.net>.
https://bugzilla.gnome.org/show_bug.cgi?id=742456
This is necessary as we are using _GLIB_AUTOPTR_TYPENAME and
_GLIB_AUTOPTR_FUNC_NAME in gtype.h for G_DECLARE_DERIVABLE_TYPE and
G_DECLARE_FINAL_TYPE, but _GLIB_AUTOPTR_TYPENAME and
_GLIB_AUTOPTR_FUNC_NAME expand to nothing on non-GCC, causing builds on
non-GCC to break, due to bad typedef and function definitions.
This patch defines a new private macro which does what is needed on GCC
builds and does nothing on non-GCC builds, thus fixing the build.
https://bugzilla.gnome.org/show_bug.cgi?id=743640
Add the missing 'none' argument to this macro in the non-GCC case. The
none parameter was added after the others and I forgot to update the
non-GCC case.
https://bugzilla.gnome.org/show_bug.cgi?id=743640
Add g_auto() and g_autoptr() as helpers for declaring variables with
automatic cleanup.
Add some macros to help types define cleanup functions for themselves.
Going forward it will be an expectation that people use this macro when
creating a new type, even if they do not intend to use the auto-cleanup
functionality for themselves.
These new macros only work on GCC and clang, which is why we resisted
adding them for so long. There exist many people who are only
interested in writing programs for these compilers, however, and a
similar API in libgsystem has proven to be extremely popular, so let's
expose this functionality to an even wider audience.
We ignore deprecation warnings when emitting the free functions, which
seems suspicious. The reason that we do this is not because we want to
call deprecated functions, but just the opposite: sometimes the free
function will be an _unref() function that is only AVAILABLE_IN newer
versions, and these warnings are also implemented as deprecation
warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=743640
This adds a public API where one can use to see whether the running version
of Windows where the code is run is at least the specified version, service
pack level, and the type (non-server, server, any) of the running Windows
OS.
This API is done as:
-GetVersion()/GetVersionEx() changed in the way they work since Windows 8.1
[1][2], so a newer mechanism to check the version of the running Windows
operating system is needed. MSDN also states that GetVersion() might be
further changed or removed after Windows 8.1. This provides a wrapper for
VerfyVersionInfo() as well in GLib for most cases, which was recommended
in place of g_win32_get_windows_version() for more detailed Windows
version checking.
-Provides an OS-level functionality check, for those that we don't need to
venture into GetProcAddress(), and also to determine system API behavior
changes due to differences in OS versions.
Also added a note for the g_win32_get_windows_version() API that since the
behavior of GetVersion() which it uses, is changed since Windows 8.1, users
of the API should be aware.
[1]:
http://msdn.microsoft.com/zh-tw/library/windows/desktop/ms724451%28v=vs.85%29.aspx
[2]:
http://msdn.microsoft.com/zh-tw/library/windows/desktop/ms724451%28v=vs.85%29.aspxhttps://bugzilla.gnome.org/show_bug.cgi?id=741895
