We need to re-get the size of tzi.DaylightName before we call
RegQueryValue() because the buffer might not have enough room to hold the
value for tzi.DaylightName that would be acquired by RegQueryValueExA(),
even though the size of tzi.DaylightName and tzi.StandardName is the same.
This is a pitfall of RegQueryValue()[1] as not doing this can result in an
ERROR_MORE_DATA (234) failure, causing the acquisition of tzi.DaylightName
to fail.
This will fix the gdatetime/equal test, amongst some other tests in
gdatetime, at least on certain non-English version of Windows.
[1]: http://social.msdn.microsoft.com/Forums/vstudio/en-US/84f90854-e90c-4b63-8fc1-655a0b4645fd/regqueryvalueex-returns-errormoredatahttps://bugzilla.gnome.org/show_bug.cgi?id=719344
If two GValues are transformable, it implies they are compatible,
so you do not need to check for compatibility yourself. Bump the
documentation to reflect this fact.
https://bugzilla.gnome.org/show_bug.cgi?id=707111
Adds some code examples how functions can be used. Adds a hint
to look at GQueue if access to the start and the end of the list
is required.
applying comments from Emmanuele Bassi and adds some more
improvements to clarify how functions should be used.
https://bugzilla.gnome.org/show_bug.cgi?id=683388
GLib has a pervasive assumption that function and data pointers are
basically interchangeable, which is true in all modern ABIs,
but not actually guaranteed by ISO C. If someone tries to use GLib on a
platform where function and data pointers are different sizes, fail early.
https://bugzilla.gnome.org/show_bug.cgi?id=688406
It is possible (but unlikely) that there will be a non-empty list of
pending dispatches when we remove the last ref from a GMainContext.
Make sure we drop the refs on the sources appropriately.
Add a (now-working) testcase that demonstrates how to trigger the issue.
https://bugzilla.gnome.org/show_bug.cgi?id=139699
glocalfile.c: In function 'g_local_file_measure_size_of_file':
glocalfile.c:2654:3: warning: passing argument 2 of 'g_lstat' from
incompatible pointer type [enabled by default]
if (g_lstat (name->data, &buf) != 0)
^
In file included from glocalfile.c:68:0:
../glib/gstdio.h:135:5: note: expected 'struct GStatBuf *' but argument
is of type 'struct _stati64 *'
https://bugzilla.gnome.org/show_bug.cgi?id=711547
gdbusauthmechanismexternal.c: In function 'mechanism_client_initiate':
gdbusauthmechanismexternal.c:355:3: warning: 'initial_response' may be
used uninitialized in this function [-Wmaybe-uninitialized]
return initial_response;
^
gdbusauthmechanismexternal.c:332:10: note: 'initial_response' was
declared here
https://bugzilla.gnome.org/show_bug.cgi?id=711547
glocalfileinfo.c: In function '_g_local_file_info_get':
glocalfileinfo.c:1955:11: warning: passing argument 3 of
'get_thumbnail_attributes' from incompatible pointer type [enabled by
default]
get_thumbnail_attributes (path, info, &statbuf);
^
glocalfileinfo.c:1285:1: note: expected 'const struct GStatBuf *' but
argument is of type 'struct _stati64 *'
get_thumbnail_attributes (const char *path,
https://bugzilla.gnome.org/show_bug.cgi?id=711547
If the action is stateful and the user doesn't have their own activate handler
then do some reasonable things for ourselves.
After a lot of experience using stateful GSimpleAction it turns out that
people almost always end up using it in the same ways:
A boolean-typed stateful action with no parameter is most likely going
to want to be toggled. Any other type of action that has the parameter
type equal to the state type probably intends for activation to
represent a request to change the state.
This patch implements those two cases. This will let people stop
writing their own trivial handlers over and over.
https://bugzilla.gnome.org/show_bug.cgi?id=722503
