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
Include an example main() function, and include a link to the gettext
manual’s section on integrating gettext with build systems.
That should work as a complete reference for how to add i18n support to
an application.
https://bugzilla.gnome.org/show_bug.cgi?id=742972
Update config.h.win32.in and glibconfig.h.win32.in so that they will be
in-line with the ones that are produced with configure.ac, for use on
Windows builds.
Thanks to Philip Withnall for pointing out the changes needed to update
glibconfig.h.win32.in in bug 727829.
We should not advise people to cast the result of
g_hash_table_get_keys_as_array() to a type that looks suitable for use
with g_strfreev(). Advise to use (const gchar **) instead.
We intend to keep the list of poll records sorted by (integer) file
descriptor, but due to a typo we are actually keeping it sorted by
pointer address of the GPollFD.
Fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=11059
It simplifies a little bit some code that inserts data relative to a
GList location, that might be NULL for the tail of the queue. A NULL
sibling is probably less useful for insert_after(), so it's more for
consistency with insert_before().
https://bugzilla.gnome.org/show_bug.cgi?id=736620
If a given fd is being polled by multiple sources, we used to pass it
multiple times to g_poll(), which is technically illegal (and not
supported by the select()-based fallback implementation of poll() in
gpoll.c), and also made it more likely that we'd exceed the maximum
number of pollfds.
Fix it to merge together "duplicate" GPollFDs. The easiest way to do
this involves re-sorting context->poll_records into fd order rather
than priority order. This means we now have to walk the entire pollrec
list for every g_main_context_query() and g_main_context_poll(),
rather than only walking the list up to the current max_priority.
However, this will only have a noticeable effect if you have tons of
GPollFDs, and we're already too slow in that case anyway because of
other O(n) operations that happen too often. So this shouldn't change
much (and the new poll API will eventually let us be cleverer).
Remove some win32-specific code which did the same thing (but was
O(n^2)).
https://bugzilla.gnome.org/show_bug.cgi?id=11059
We called getopt() to try to find out of the platform on which we are
running defaults to strict POSIX-style argument handling (ie: flags
following the first filename are considered as further filenames rather
than flags).
This is the default case on BSDs, for example. It is also the case on
GNU systems with the POSIXLY_CORRECT environment variable set.
Unfortunately many of our tools rely on being able to accept commandline
arguments in the non-strict ordering and the code for making these calls
is spread widely (for example in Makefile fragments invoking some of our
build tools).
For this reason we need to revert the getopt() check and only enable
strict POSIX mode in the case that the application explicitly opts into
it using the _set_strict_posix() API.
This also fixs a failure to build on Windows due to missing getopt().
https://bugzilla.gnome.org/show_bug.cgi?id=723160
With this patch it is fine to call g_hash_table_lookup and
g_hash_table_remove from destroy notification functions. Before
this could lead to an infinitie loop if g_hash_table_remove_all
was used.
https://bugzilla.gnome.org/show_bug.cgi?id=695082
Add a "posixly correct" mode to GOption to stop parsing arguments as
soon as the first non-option argument is encountered.
We determine the default value on the basis of duplicating the behaviour
of the system getopt() implementation (which we directly check the
behaviour of at runtime). On GNU systems this allows the user to modify
our behaviour using POSIXLY_CORRECT.
The user can change the value by g_option_context_set_strict_posix(),
which might be useful for some usecases of GOptionContext (as mentioned
in the doc string of this new function).
https://bugzilla.gnome.org/show_bug.cgi?id=723160
g_get_monotonic_time() and g_get_real_time() now always use different
clocks, so we cannot avoid correcting for their offset. Fixes failure
to time out on Mac OS X.
https://bugzilla.gnome.org/show_bug.cgi?id=738197
Internal allocation size (array->alloc) was being kept to 0 when a new
GByteArray was created from an already existing heap-allocated buffer.
Among other things, this was making g_byte_array_set_size() fully clear all
the buffer contents (not just the newly allocated memory) when
G_DEBUG=gc-friendly was being used...
if (G_UNLIKELY (g_mem_gc_friendly))
memset (array->data + array->alloc, 0, want_alloc - array->alloc);
https://bugzilla.gnome.org/show_bug.cgi?id=738170
