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
Add g_option_context_parse_strv() that obeys the normal memory conventions for
dealing with a strv instead of assuming that we're dealing with the 'argv'
parameter to main().
This will help for using GOptionContext with GApplication.
https://bugzilla.gnome.org/show_bug.cgi?id=721947
The names of the month (and abbreviations) are specific to the Windows
system locale, so we need to use SetThreadLocale() to set the locale of
the running program to en-US so that it will parse "March" and "Sept" etc.
correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=719344
Windows will not allow one to write to a temp file opened by g_mkstemp()
by opening another fd associated with it before one closes the fd that
is returned by g_mkstemp(), which will cause the test_save test to fail.
Fix this by using a variable to store the fd from g_mkstemp() and checking
it, and call close() on that variable before attempting to call
g_key_file_save_to_file() on the temp file as that will attempt to open
another fd (which would not work) associated with that temp file.
https://bugzilla.gnome.org/show_bug.cgi?id=719344
Fix some races introduced in be2c7b83c4a9c9d3aa76b1499c27ab19e0f4e470
while keeping the property that multiple handlers for the same unix
signal all get dispatched.
Also fix the behaviour of the source checking for pending signals when
it's created. No matter what we do here (clear the pending flag or not)
there is something that can go wrong.
If we clear the flag, we may prevent other sources from being
dispatched. If we don't clear it, we may end up dispatching the same
source twice (if we manage to dispatch it from its own thread before the
GLib worker has a chance to run).
Instead, run the full dispatch procedure when a new source is added. It
actually doesn't matter what thread this runs in since the lock is held.
https://bugzilla.gnome.org/show_bug.cgi?id=711090
The existing tests were accidentally using the same test data
twice. Fix that, and add another set of tests that exercise
the filename collation special cases.
