Make sure that the macros work properly with the range of types that
they are documented to work with and ensure that no strict aliasing
warnings are issued (even at the highest warning level).
https://bugzilla.gnome.org/show_bug.cgi?id=650935
Ensure callers get a warning if they pass a bad length.
Split into a separate commit and changed to order index before
n_children by Colin Walters <walters@verbum.org>
During the recent refactorings of GHashTable a bug was introduced
where removing all nodes from a hash table would leave tombstones
behind, but make the counts appear like there are none.
Reported and tracked down by Carlos Garnacho,
https://bugzilla.gnome.org/show_bug.cgi?id=651141
This commit also adds a test that checks the internal consistency
of GHashTable over several insert/remove/remove-all operations.
The grouping in files/headers is not used anymore, and
the function attributes neither. Adapt abicheck scripts
and .def file generation rules accordingly.
When using gcc builtins for atomic operations, provide them
as macros, so gcc can see the builtins and do optimizations.
This change gives considerable speedups in bitlocks, which
use atomic operations heavily, see bug 650458.
Also, don't define G_ATOMIC_OP_MEMORY_BARRIER_NEEDED unconditionally
when using gcc builtins.
https://bugzilla.gnome.org/show_bug.cgi?id=617491
When loading a keyfile the incoming bytes are fed
to a line buffer to get parsed each time a new line
is encountered.
The code that fills the line buffer does it inefficiently,
one byte at a time.
This commit changes that code to look ahead at the incoming
bytes for the next '\n' character and then fill the line buffer
all at once.
https://bugzilla.gnome.org/show_bug.cgi?id=650211
When loading a key file, the keys and values of individual lines
are allocated once when copied and trimmed from the parse buffer
and allocated/copied again when added to the lookup map.
This commit avoids the second pair of allocations by introducing
a new function g_key_file_add_key_value_pair that gives the
lookup map direct ownership of the key and value copied from the
parse buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=650211
Make g_date_time_format() support some useful format modifiers from
strftime(). This commit adds support for the POSIX 'O' modifier
(alternative digits), as well as the -/_/0 padding modifiers, which
are a GNU strftime() extension.
https://bugzilla.gnome.org/show_bug.cgi?id=648678
g_variant_new_string() hits a g_return_if_fail() when given invalid
UTF-8. That's certainly the right thing to do, but
g_variant_builder_add() uses this function internally and crashes when
it returns NULL due to the user passing a non-utf8 string.
We can protect the internal code by returning "[Invalid UTF-8]" in this
case while also making the problem easier to debug (and less fatal).
Closes#632631.
_GNU_SOURCE must be defined before including any other (system)
header, so defining it in glib-unix.h (and hoping no one has included
anything else before that) is wrong. And the "#define _USE_GNU"
workaround for this problem in gnetworkingprivate.h is even wronger
(and still prone to failure anyway due to single-include guards).
Fix this by defining _GNU_SOURCE in config.h when building against
glibc. In theory this is bad because new releases of glibc may include
symbols that conflict with glib symbols, which could then cause
compile failures. However, most people only see new releases of glibc
when they upgrade their distro, at which point they also generally get
new releases of gcc, which have new warnings/errors to clean up
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=649201
Make hash tables start out in a mode in which they don't store
values at all, until the first insertion of a non-identical
key-value pair.
This reduces memory requirements by 1/3 when using hash tables
to store sets.
Based on a patch by Morten Welinder,
https://bugzilla.gnome.org/show_bug.cgi?id=644437
Kill g_hash_table_lookup_node and rename g_hash_table_lookup_node_for_insertion
to g_hash_table_lookup_node. Since at this point we already check for
toombstones in all callers of g_hash_table_lookup_node this doesn't make
a difference.
https://bugzilla.gnome.org/show_bug.cgi?id=644437
This reduces memory requirements by 1/6 on 64-bit machines since
no padding is needed. It also puts less strain on the memory
allocator since we no longer need one giant slab of memory.
https://bugzilla.gnome.org/show_bug.cgi?id=644437
On Linux with gdb, it's much more convenient to debug programs using
G_DEBUG=fatal-warnings if we send SIGTRAP instead of abort() by
default. The default handler for both is to terminate the process.
In particular this makes it more easily possible to debug a warning
that's not the first in a program; you can skip past it and
go to the warning you care about.
The "aborting..." message is removed since it's no longer accurate,
and anyways was never very useful; crashes should show up in ABRT/apport
type crash catching systems.
https://bugzilla.gnome.org/show_bug.cgi?id=648423
This new API allows watching a few select Unix signals;
looking through the list on my system, I didn't see anything
else that I think it'd reasonable to watch.
We build on the previous patch to make the child watch helper thread
that existed on Unix handle these signals in the threaded case.
In the non-threaded case, they're just global variables.
https://bugzilla.gnome.org/show_bug.cgi?id=644941
GLib historically has been designed to be "mostly" portable; there
are some functions only available on Unix like g_io_channel_unix_new(),
but these are typically paired with obvious counterparts for Win32.
However, as GLib is used not only by portable software, but components
targeting Unix (or even just Linux), there are a few cases where it
would be very convenient if GLib shipped built-in functionality.
This initial patch is a basic wrapper around pipe2(), including
fallbacks for older kernels. This pairs well with the
existing g_spawn_*() API and its child_setup functionality.
However, in the future, I want to add a signal() wrapper here,
complete with proxying the signal to a mainloop. I have initial code
for this, but doing it sanely (including factoring out gmain.c's
private worker thread), is a complex task, and I don't want to block
on that.
See also gwin32.h for Win32 specific functionality.
https://bugzilla.gnome.org/show_bug.cgi?id=644941
In the previous code, if the timezone was pulled out of the cache again
just as the last reference was being dropped, the cache code will
increase its refcount and return it while the unref code was freeing it.
Protect against that.
Closes#646435.
g_tls_certificate_list_new_from_file() was leaking the file contents,
and GSource was leaking the GSourcePrivate structure that got
created when using child sources.
We really shouldn't use <unknown> when we can perfectly easily
get argv0 out of /proc. This avoids people having to pass argv
down into gtk_init/g_option_context_parse etc., which is important
because GTK+ uses it to initialize the WM_CLASS, which in turn
GNOME Shell consumes for application tracking.
https://bugzilla.gnome.org/show_bug.cgi?id=644309
Add a new function that allows the parser to check that the current
token is equal to a given string without consuming the token.
Reimplement the 'consume' function in terms of the new function.
Robert Ancell discovered that the GVariant parser messes up pretty badly
when the type of a tuple is specified and the tuple in the text being
parsed has a different number of elements (but otherwise matching child
types).
Check that we have the expected number of elements.
Closes#644786.
* Since the GLib translations are lazily initialized, we need an
internal wrapper for g_dpgettext() that does the initialization
in the same way as glib_gettext()
* We need to use the glib domain defined by GETTEXT_PACKAGE
rather than than the application's domain.
https://bugzilla.gnome.org/show_bug.cgi?id=644607
These are the updates to the autotools files to
ensure the expansion of the GIO, GLib and GObject
project files (*.vcxproj, *.vcxproj.filters) and to
enable the distribution of the VS2010 project files
The actual VS2010 project files will follow shortly
g_variant_new("as", NULL); now gives an empty array of strings, for
example.
This was documented as working already, but was never actually
implemented (due to the fact that it muddies the water when considering
maybe types). It's being implemented now because its convenience to
programmers exceeds any damage done to the conceptual purity of the API.
Bug #640807 makes a reasonable case for why it's better to have your
program crash outright in the case of memory errors. With this
modification, GVariant is far more likely to do that in the case that a
GVariant pointer is used shortly after being freed.
When g_key_file_parse_data() encountered \n, it was checking the previous
character in the current input buffer for a \r to erase, rather than the
previous character in the parse buffer. If g_key_file_load_from_file()
was given a file with a \r\n sequence straddling a 4 KB boundary, the \n
would be the first character in the input buffer, so the \r would not be
properly stripped.
Bug #640695.
Found-by: Jan Harkes <jaharkes@cs.cmu.edu>
One new GUnicodeBreak enum member. Three new GUnicodeScript members,
and one member renamed to fix a typo.
Tests, docs, and scripts are updated. PCRE update still needed.
The 12h mode hour format is computed by taking the
24h mode hour format modulo 12.
The conversion results in 12 noon getting erroneously
converted to 0.
This commit makes noon get the same special handling
as midnight.
