The former is now deprecated, so it makes sense to base its
implementation on the latter, rather than the other way around.
This introduces no functional changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1438
GTimeVal is subject to the year 2038 problem, since its `tv_sec` field
is a `glong`, which is 32 bits on 32-bit platforms.
Use `guint64` to represent microsecond-precision time since the Unix
epoch; or use `GDateTime` for full date/time representation.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1438
It’s not Y2038-safe, as it’s 32-bit. While it was previously deprecated
in the documentation, now add the deprecation annotation for the
compiler.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1438
This is a simple wrapper around g_date_time_format_iso8601() which
always produces ISO 8601 dates, without people having to remember the
format string for them (and with the convenience of terminating UTC
dates with ‘Z’ rather than ‘+00’).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1438
Only redefine g_message() and friends to use structured logging if the
compiling code is OK with depending on GLib functionality from ≥2.56.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1847
Try to create the complete path right away and fall back
to creating all path elements one by one.
This also helps to avoid TOCTTOU problems and avoids walking
the path all the time, providing a nice performance gain, by
avoiding syscalls.
Ignore ENOENT errors up until the last element while trying to create each
of the path elements in case a restricted file-system is being used where
path elements can be hidden or non-accessible.
We're using the `install` argument for configure_file() all over the
place.
The support for an `install` argument for configure_file() was added in
Meson 0.50, but we haven't bumped the minimum version of Meson we
require, yet; which means we're getting compatibility warnings when
using recent versions of Meson, and undefined behaviour when using older
versions.
The configure_file() object defaults to `install: false`, unless an
install directory is used. This means that all instances of an `install`
argument with an explicit `true` or `false` value can be removed,
whereas all instances of `install` with a value determined from a
configuration option must be turned into an explicit conditional.
If searching for an element which is smaller than every element in the
array (i.e. the element being searched for is not in the array), the
previous g_array_binary_search() implementation would underflow in the
calculation `right = middle - 1`, and end up trying to dereference an
element way off the right of the array.
Fix that by checking the additions/subtractions before doing them, and
bailing if the bounds are hit. We don’t need to check `middle <
G_MAXUINT`, as `middle` is bounded above by `right`, which is always `<=
_array->len - 1`, and `_array->len <= G_MAXUINT`.
Add some tests for that, and for not-present elements in the middle of
the array. Previously, the tests only checked for not-present elements
which were bigger than every element in the array.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If `right` and `left` are both near `G_MAXUINT`, it’s possible for the
addition to overflow, even if the eventual result would fit in a
`guint`. Avoid that by operating on the difference instead.
The difference is guaranteed to be positive due to the prior `left <=
right` check.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The allocation size was set correctly before, but not the array length,
so the copied array appeared to have zero elements.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
We need to enable building the dirent and gnulib sources for clang-cl,
as we are still using the Microsoft-style headers and lib's and CRT.
We need to also do this for the following, for similar reasoning:
-Symbol export (via __declspec(dllexport))
-Dependency discovery without pkg-config files
-long long and ssize_t detection
We do, however, enable the autoptr tests for clang-cl builds. Note that
at this point real MSVC builds are still better supported than clang-cl
builds, and it will likely remain so for at least the near future,
alhtough real MSVC builds of the GTK stack are consumable and are usable
by clang-cl.
Use the GCC-style definition for the deprecation warning macros so that
builds using those won't break due to how they are placed as clang-cl
seems to not support __declspec(deprecated) very well. Also make sure
that we do indeed support the temparary disabling of deprecation
warnings on clang-cl, as the MSVC ones don't really work on clang-cl.
clang-cl does support __attribute__((cleanup)), which is what is used
for the g_auto* macros, but neither it, nor clang.exe defines __GNUC__
when they are used in a MSVC cmd.exe environment. It does, however,
define __clang__.
So, check for the presence of the __clang__ macro to enable g_autoptr as
well, so that we can build things with MSVC builds that make use
of g_autoptr via pretending to be MSVC by using clang-cl.
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.
