The GLib units policy used to be that 'KB' means 1024 bytes, 'MB' means
1024 KB, 'GB' means 1024 MB, etc.
Those days are over, but we have a deprecated function that still works
that way. It contains the string "KB", marked for translation, which
has been a source of confusion for translators on multiple occasions.
https://bugzilla.gnome.org/show_bug.cgi?id=687516
Add the PlatformToolset tag to the project configs so that we can use add a
simple script later to the autotools files to copy the projects and change
the value (v100 -> v110) of that tag (and other simple changes) in order
that we can quickly provide and maintain support for Visual Studio 2012
with minimal effort.
Note that at the moment GLib does not yet support the API/SDK requirements
for Windows 8 Modern UI (formerly known as Metro), but this paves the very
initial step.
bytes_read and bytes_written are (out) arguments, and the return value must be
a byte array instead of utf8, as otherwise the function would only support
UTF-8 locales/file names.
I'm normally a big fan of small atomic commits, but I also want to get
things done this afternoon...
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=687441
Reviewed-by: Colin Walters <walters@verbum.org>
These both existed in 2.34.1, but are not exposed in headers, and were
meant to be private. Making them static (in commit 84475e43) was
technically an ABI break, and in particular it causes abicheck.sh to fail.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=687441
Reviewed-by: Colin Walters <walters@verbum.org>
This is preparatory work for a future commit which will add a
"catchall" waitpid API. If we don't synchronize here with the worker
thread, race conditions are possible.
This also ensures we have an error message if someone adds a child
watch for a nonexistent pid, etc. Previously, we'd simply keep
calling waitpid() getting ECHILD, and ignoring it until the source was
removed. Now, we g_warning() and fire the source.
Thirdly, this ensures that the waitpid() call in gmain handles EINTR,
like the g_spawn_sync() one did.
https://bugzilla.gnome.org/show_bug.cgi?id=687061
We're not going to depend on gnome-common (I assume) so this patch
nicks the systemd macro to test for compiler flags, and uses it to set
a similar set of -Werror=foo as the gnome-common one does.
See https://bugzilla.gnome.org/show_bug.cgi?id=608953
See https://mail.gnome.org/archives/desktop-devel-list/2012-July/msg00100.html
If we're going to be setting more strict compiler flags for GNOME, we
should really ensure GLib builds with them first, as it's kind of the
model citizen.
In particular, you can see several times that downstreams such as
Debian have come in and fixed -Wformat-security bugs. We should never
let those get into tarballs, or even commits.
https://bugzilla.gnome.org/show_bug.cgi?id=687385
Even private functions that are actually called across compilation
units should have prototypes. For g_dbus_action_group_sync(), create
one in gdbusactiongroup-private.h
https://bugzilla.gnome.org/show_bug.cgi?id=687385
Sadly, g_slice_debug_tree_statistics is conditionally part of the
public ABI. We might as well make it conditionally part of the API as
well, even though this will require people actually using it to
https://bugzilla.gnome.org/show_bug.cgi?id=687385
Basically due to a combination of va_args semantics around
signed/unsigned ints, this test case fails on ppc64. At the moment,
we have as yet to find any real-world consumer with such a large
enumeration value.
Unfortunately, the possible fixes for this are extremely invasive;
we would have to define a new enum API.
Given both of these facts, we believe it makes the most sense at the
current time to simply not test this. If we at a later time determine
there is such a real-world consumer, we can look at doing the
necessary fixes.
https://bugzilla.gnome.org/show_bug.cgi?id=686662
On platforms where dependent loads can be reordered (alpha) and we have
exotic implementation of pthread_mutex_lock() it could be possible that
our implementation of g_mutex_lock() is unsafe.
Always use atomic operations to avoid this possibility.
https://bugzilla.gnome.org/show_bug.cgi?id=686191
Add some extra protection when 'preparing' a group that doesn't yet
contain any menus. This can happen if you subscribe to a group that
doesn't yet exist.
It was possible to crash any application using
g_dbus_connection_export_menu_model() by requesting a non-existent
subscription group over the bus.
In practice this only happened in races -- where the proxy sees a group
that exists and queries it, but by the time it does, it's already gone.
https://bugzilla.gnome.org/show_bug.cgi?id=687089
Applications that use glib should not invoke waitpid with a first
argument that is nonpositive, because when such a waitpid is run in
one thread and glib waits for a subprocess in another, there is a race
condition, and the former waitpid can reap a process that was intended
for the latter. Mention this in the documentation for
g_child_watch_source_new, and in the diagnostic generated by
g_spawn_sync when its waitpid fails with errno equal to ECHILD.
Signed-off-by: Colin Walters <walters@verbum.org>
http://bugzilla.gnome.org/show_bug.cgi?id=687075
This is installed by automake. By maintaining it in git, we create
merge conflicts as people build with different versions of automake.
Just use 'mkdir -p' instead in gettext. Should be portable enough.
https://bugzilla.gnome.org/show_bug.cgi?id=686839
Allow GDBusObjectManagerClient to work on peer to peer DBus
connections. Don't require that a unique bus name is available
for the object manager, if the owned bus name is NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=686920
When building the file attribute table info for local files, use
thumbnail paths in $XDG_CACHE_DIR/thumbnails/large in addition to
$XDG_CACHE_DIR/thumbnails/normal.
Failing to do this would cause an application that creates large
thumbnails by default to never find any value for
G_FILE_ATTRIBUTE_THUMBNAIL_PATH, with no
G_FILE_ATTRIBUTE_THUMBNAILING_FAILED set, which might cause the
application to either think thumbnailing is still in progress, or
blindly requeue thumbnail operations in a loop.
Large thumbnails are generally preferred, so we now default to the path
of a large thumbnail (in case both are present).
https://bugzilla.gnome.org/show_bug.cgi?id=686895
