It’s confusing and often doesn’t help the user. Match the error code and
come up with a more UI-appropriate error message.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
However, it's fine to call it when building for the debug target
(which uses the debug CRT and hence sets -D_DEBUG), so let's keep that
around.
The Windows App Certification Kit only runs on apps built in release
mode.
These macros wrap functions which were only introduced in certain
versions of GLib. The functions are correctly marked as introduced in
those versions, but the macros aren’t, which can result in not getting
appropriate deprecation warnings if you’re using those APIs when you
have said you’re targeting older GLib versions using
`GLIB_VERSION_MAX_ALLOWED`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #1860
We require a newer SDK version now, so this is not needed.
Specifically, we set _WIN32_WINNT to 0x0601, which sets our SDK
requirement to Windows 7+, and this code is only needed for MSVC 5.0,
which is ancient.
It’s confusing and often doesn’t help the user. Match the error code and
come up with a more UI-appropriate error message.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If the dup(stderr) returns '-1' (an error occured), then the program
shouldn't call a 'close(stderr); dup(old_err);' after the exec() failed.
Fix issue #1880
A static analysis run noted that we weren't freeing the cmdline in the
error path here. We can just make this an assertion instead; I just
checked the kernel code, and it just usees a seq_printf() here which
will NUL terminate.
This fixes the following warning, by making the compiler checks for the
`pop` match those for the `push`:
```
[221/1124] Compiling C object 'glib/tests/d796b50@@mem-overflow@exe/mem-overflow.c.o'.
../glib/tests/mem-overflow.c:204:24: warning: pragma diagnostic pop could not pop, no matching push [-Wunknown-pragmas]
#pragma GCC diagnostic pop
```
Signed-off-by: Philip Withnall <withnall@endlessm.com>
These are copies of the existing tests for `g_time_val_from_iso8601()`,
with the test strings which fail for `GDateTime` commented out. This is
OK, as it’s documented as only accepting a subset of ISO 8601 (and for
some of the test vectors, it’s debatable whether they’re actually valid
ISO 8601, depending on how you interpret the valid bounds of timezone
offsets — some interpretations of the available documentation would say
that timezone offsets should never be ≥24 hours or ≥60 minutes).
There is one test string which is not accepted by
`g_time_val_from_iso8601()` but which is accepted by `GDateTime`, as
`g_date_time_new_from_iso8601()` actually accepts RFC 3339, which is a
little more liberal than ISO 8601. Fun times. See
https://tools.ietf.org/html/rfc3339#section-5.6.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Some malformed ISO 8601 date/time strings were causing an assertion
failure when passed to `g_date_time_new_from_iso8601()`, due to a
mismatch between the bounds checking of timezone offsets in `GDateTime`
and `GTimeZone`. Fix that and add a unit test for it.
oss-fuzz#16101
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Since we transitioned from Bugzilla to GitLab, we have two forms of bug
references in the GLib source code: old (but still relevant) Bugzilla
links, and newer GitLab links. We can’t use a single base for the two,
so have to either build incorrect URIs, or provide the full URI in
g_test_bug().
It’s always seemed a bit of an over-optimisation to provide the bug base
separately from the bug ID, so relax the assertions and documentation
around g_test_bug_base() so that g_test_bug() can be used on its own.
The old usage patterns are still supported unchanged.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
On x86 (and apparently most other Linux architectures), the union
with the signal handler is the first member, but on MIPS Linux,
the first struct member is sa_flags (possibly done to be compatible
with IRIX). Zero out the struct and fill in the field we want by name.
Signed-off-by: Simon McVittie <smcv@collabora.com>
When using the mingw printf shims for C99 compat the msvc format specifiers don't work
and the build fails.
Ideally we would use glib functions which abstract this away, but in the error handler context
we shouldn't call back into glib. And for scanf we don't have a glib wrapper.
Instead call the "secure" versions provided by the win32 API (_snprintf_s/fprintf_s/sscanf_s)
which mingw doesn't replace.
We currently check in multiple places if vsnprintf/snprintf/printf are
good and if not use gnulib. This case was not checking for printf which
made the build fail with recent mingw-w64 where snprintf was improved to
pass all glib checks but printf still doesn't.
Commit 6f55306e04e5 unintendedly broke error handling for other
error conditions than ENOENT along the path, like EPERM. It wanted
to ignore ENOENT on all elements except the last in the path, but
in doing that it ignored any other error that might happen on the
last element.
https://gitlab.gnome.org/GNOME/glib/issues/1852
You may expect funny effects from passing invalid UTF-8, but not
that funny. The assert will probably be a better and more immediate
confirmation of an error than invalid writes under the address of the
string copy.
https://gitlab.gnome.org/GNOME/glib/issues/1863
This comment was correct until commit adf1f98f62, when the `GTimeVal`
which the result was put into (introducing the Y2038-unsafety) was
dropped.
The adjustment and scaling of the `FILETIME` should not make it
Y2038-unsafe: the maximum `FILETIME` is 2^64-1. Subtracting the epoch
adjustment and dividing by 10 gives the timestamp 1833029933770955161,
which is in June 58086408216 (at just after 3am UTC). I think that’s
enough time to be going on with.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1438
This requires some reworking of the internal g_date_time_new_from_unix()
function, since it previously operated in seconds, which wasn’t high
enough resolution — the g_get_current_time() code path used to operate
in microseconds.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1438
