Windows does not recognize the "America/Recife" as a valid timezone
identifier, so setting the TZ envvar to that will result in "UTC" to
be returned on Windows.
Instead, set TZ to be the Windows equivilant "SA Eastern Standard
Time", and see whether that is indeed our identifier when we create the
GTimeZone using that.
On Windows, we may be using the US DST boundaries by using the default
"Pacific Standard Time" for rules_from_windows_time_zone() in
rules_from_identifier(). This has the unfortunate side-effect of
hardcoding the out_identifier to "Pacific Standard Time", which is
likely not what we want.
Instead, upon retrieving the items successfully using
rules_from_windows_time_zone ("Pacific Standard Time", ...), we just
set the out_identifier to whatever identifier that was passed into
rules_from_identifier().
Update the gdatetime test program to make use of the updates that was
done in gtimezone.c in the previous commit, so that we don't have to
worry what language version of Windows the tests are being run in, but
instead be assured that we produce and check for the English-language
time zone name strings.
Also, instead of testing for "Pacific Standard Time" in
test_GDAteTime_printf(), use GetDynamicTimeZoneInformation() to get the
actual time zone string (where the system running the test program is)
we want to check for, because on Windows the actual result will be
dependent on which timezone the system running the test program is in.
https://bugzilla.gnome.org/show_bug.cgi?id=719344
The existing method of using RegQueryValueExW() to query the Std/Dlt
strings can only retrive the localized versions of those strings, so
that means they will vary by the language version of Windows. Instead,
use RegQueryValueExW() only as a fallback when RegLoadMUIStringW() fails,
as RegLoadMUIStringW() can query for the Std and Dlt strings in
whatever language we need by setting the locale stuff programatically on
the fly.
We are going to use RegLoadMUIStringW() in the next commit, since there
is no real RegLoadMUIStringA() function (it exists as a stub only).
This is done so that we are consistent along the way
Also fix rule_from_windows_time_zone_info() as we can't just do a strncpy()
of tzi->StandardName and tzi->DaylightName directly, as they are wchar_t/
gunichar2 strings, where we must convert to UTF-8 first.
https://bugzilla.gnome.org/show_bug.cgi?id=719344
We said the type must support being cleaned up and will be cleaned up in
an appropriate way, but in order to figure out how to do that, you had
to jump forward in the documentation to the other macros. Just say them.
This is a follow-up to a0c7f85437093b073b3e3b2c9cb337065b6ea896.
In addition LC_MESSAGES, we should remove LC_ALL from the environment
as well. Otherwise, LC_ALL overrides LC_MESSAGES, causing the test to
fail on FreeBSD when LC_ALL is set to a non-English locale.
This (dubious) testcase fails before the previous commit due to errno
being clobbered by the interrupted wait on the contended mutex. The
previous commit fixes that.
The testcase is dubious because, in theory (as per POSIX),
g_cond_wait_until() is permitted to return TRUE at any time for any
reason, due to so-called "spurious wakeups". Having a testcase that
asserts that the return value should be FALSE is therefore fundamentally
broken. We do it anyway, though.
We're only really trying to test a bug in our homemade Linux/futex
implementation here, and it takes a fair amount of effort to actually
convince the old code to fail (including some system stuff which
probably isn't available on Windows). There's also the spurious wakeup
situation mentioned above to worry about on other systems. For all of
those reasons, this test is only enabled on Linux.
The return value from `g_cond_wait_until()` is calculated, based on the
value of `errno` after reacquiring the mutex. This is a problem because
`errno` can be overwritten in the case the mutex is contended (in which
case the slow-path code will re-enter the kernel).
Perform the calculation before reacquiring the mutex.
See merge request GNOME/glib!958
Visual Studio 2010 and later support static_assert on both C and C++,
but we can only enable it for plain-C code on Visual Studio 2013 and
later, as apparently the static_assert macro implementation will carry
out something after defining certain variables.
For C++ code, we use static_assert on Visual Studio 2010 and later.
The return value for g_utf8_normalize may be null, but the return type
is not annotated as such. This is important for language bindings for
langs that are about nullability, such as Vala and Haskell.
The static assert message is much nicer to read, and is less likely to
be misinterpreted as a false positive.
glib is built with `-std=gnu89`, but this macro will be available to
projects that use glib with c11 or gnu11.
It is unclear that why the size of the buffer was chosen to be 100
because the commit introduced the code didn't mention the reason.
POSIX defines _POSIX_HOST_NAME_MAX to be 255 and provides a way to
determine the suitable value with sysconf, so we should use it instead
of hard-coding a small value.
The g_creat() call was done in *nix style in regards to the mode parameter,
which the Windows CRT isn't going to understand (nor like, on newer CRTs).
Update the program such that it will pass, by using Windows-style
permission mode parameters for g_creat(), on Windows.
On Windows, everything is assumed as UTF-8 in g_get_filename_charsets(),
so setting G_FILENAME_ENCODING envvar has no effect, so we can just skip
the test on g_get_filename_charsets() where we try to influence it by
setting the G_FILENAME_ENCODING envvar.
On Windows, in particular the CRTs on and after Visual Studio 2012, it
is not enough just to do setlocale (LC_ALL, "") to set the default
system locale, which results in the tools that use the translated
messages to show unreadable messages when running the commmand line
tools.
This adds an entry in glib-private.h.in which denotes the appropriate
string to use for setlocale() to set the default system locale by
setting it to ".ACP" if we are building on Windows and "" for
other systems (as we are doing now).
The tools in gio/ will be updated in the next commit to make use of this
entry so that the translated messages can be shown correctly.
From grefcount.h, in order to disable warnings when G_DISABLE_CHECKS is
defined, we need to make use of the GCC-isque-only __extension__ for it
to work. This means that in the saturation tests, we can only expect no
warnings to show if we are building on GCC-isque compilers with
G_DISABLE_CHECKS defined.
This will fix the refcount-macro test on Visual Studio builds at least.
