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
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
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
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
Use the new g_option_context_parse_strv() to patch up some leaks in some
insufficiently-argv-emulating testcases in option-context.c.
This gives some test coverage of the new function while also making
option-context now leak-free.
https://bugzilla.gnome.org/show_bug.cgi?id=721947
