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
Add a note to the overview documentation for GOptionContext about why
you need to be careful about argv encoding on UNIX and about why you
should avoid argv entirely on Windows. Mention some possible
alternative approaches, including a code example.
https://bugzilla.gnome.org/show_bug.cgi?id=722025
Clarify in the documentation that the commandline arguments passed
around by GApplication (to local_command_line and returned via
g_application_command_line_get_arguments()) are in the GLib filename
encoding (ie: UTF-8) on Windows, not the system code page.
Fix the mismatch that would result from having argv passed to
g_application_run() in main() on Windows (where it is in the system
code page) by ignoring argc/argv on Windows and calling
g_win32_get_command_line() for ourselves. Document this.
This might be a slight API break on Windows: we documented that it was
possible to call g_application_run() with arguments other than argc/argv
and now doing that will result in those arguments being ignored. It has
always been recommended practice to only call g_application_run() from
main() directly, however, and all of our code examples have shown only
this. We will see if this causes any issues and consider reevaluating
the situation if so.
https://bugzilla.gnome.org/show_bug.cgi?id=722025
Add a note to the documentation for g_file_new_for_commandline_arg()
that this function is intended to operate on strings already in the GLib
filename encoding on Windows.
This has been the case for a long time, but this documents the
requirement.
https://bugzilla.gnome.org/show_bug.cgi?id=722025
This returns the command line in GLib filename encoding format (ie:
UTF-8) for use with g_option_context_parse_strv().
This will allow parsing of Unicode commandline arguments on Windows,
even if the characters in those arguments fall outside of the range of
the system codepage.
https://bugzilla.gnome.org/show_bug.cgi?id=722025
Add another difference to the freshly-added g_option_context_parse_strv:
now, on Windows, its arguments on to be in UTF-8 instead of the argv[]
encoding (from the system codepage).
The documentation teases g_win32_get_command_line() which is a new
GLib-filename-encoding-based function that will be added in a following
commit.
https://bugzilla.gnome.org/show_bug.cgi?id=722025
g_strconcat() allocates memory, it needs to be freed.
==10653== 1,400 bytes in 50 blocks are definitely lost in loss record
1,838 of 1,851
==10653== at 0x4A0645D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10653== by 0x54ACB22: g_malloc (gmem.c:102)
==10653== by 0x54ACE4D: g_malloc_n (gmem.c:343)
==10653== by 0x54C8463: g_strconcat (gstrfuncs.c:589)
==10653== by 0x4D6ED38: get_xattrs_from_fd (glocalfileinfo.c:660)
==10653== by 0x4D71622:
_g_local_file_info_get_from_fd (glocalfileinfo.c:2028)
==10653== by 0x4D731A0:
g_local_file_input_stream_query_info (glocalfileinputstream.c:356)
==10653== by 0x4C996D8:
g_file_input_stream_query_info (gfileinputstream.c:148)
==10653== by 0x4C863F6: file_copy_fallback (gfile.c:3120)
==10653== by 0x4C86DD2: g_file_copy (gfile.c:3398)
https://bugzilla.gnome.org/show_bug.cgi?id=722357
