The code was previously doing a few bits of arithmetic without checking
whether they would overflow, and hence not validating the date/time it
was parsing very strictly.
The parser is now not 100% strict, but should avoid any arithmetic
overflows which would cause an invalid result to be returned even though
g_time_val_from_iso8601() had returned TRUE.
oss-fuzz#9673
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This repurposes the existing skip-all test as "combining", since it
is no longer entirely about runs where every test-case was skipped.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If a test is marked with g_test_incomplete(), then it is expected to
fail, so when it fails the test executable should still exit 0
(or possibly 77, if all tests are either skipped or incomplete).
Signed-off-by: Simon McVittie <smcv@collabora.com>
In the test for the unit testing framework, we might as well have
exemplary behaviour. Leave behind a single call to g_assert (TRUE)
just to prove that it still works.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The TAP specification says that failing tests that are currently
expected to fail (like Automake's XFAIL) are to be reported as
"not ok", with that failure ignored as a result of the TODO
directive, with this example:
not ok 3 - infinite loop # TODO halting problem unsolved
A test reported as "ok # TODO" indicates that something that is
expected to fail has unexpectedly succeeded, similar to Automake's
XPASS.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Assigning the gpointer return value from g_atomic_pointer_get() to a
gsize variable was not making -Wbad-function-cast happy. Assign to an
intermediate gpointer variable and then cast that instead.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1475
g_test_skip() is appropriate for tests that can't run due to missing
functionality on the host system, whereas g_test_incomplete() is
for expected-to-fail tests for unimplemented functionality in the
code under test.
See also https://bugzilla.gnome.org/show_bug.cgi?id=793635 and
commit 5459b345.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Testing that an interned string is released once its last reference is
dropped is not possible without a hook into the interning machinery;
just checking that the returned pointer for the same string is going to
be different after the last release() is not guaranteed to work, as the
systema allocator is perfectly within its rights to recycle pointers, as
long as they are unique while valid.
Closes#1467
When checking that the timezone code falls back to UTC if a zone is
unknown, don’t use ‘PST’, because that can actually exist on some
systems.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1433
See previous commit; same reasoning behind the commit, except that these
sources weren’t (yet) causing `make distcheck` to fail.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Instead of messing around with EXTRA_*_SOURCES and manually handling .lo
files, why not just add gwin32.c to the GLib sources conditionally?
This will hopefully fix `make distcheck` failing due to gwin32.Plo not
being generated in the sub-builddir≠srcdir stage, due to depcomp
inexplicably not generating it. (Note that it is correctly generated in
non-distcheck builds.)
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The parser state machine for bookmark files did not handle unexpected
nesting of elements, such as a <bookmark> element inside a <title>
element — it would print a critical warning rather than returning a
GError.
Fix that, and add various unit tests for it. The set of tests includes
various other general markup tests as provided by Jussi Judin.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1035
That should format these character classes correctly in the
documentation, and prevent them being interpreted by gtk-doc as (broken)
Markdown hyperlinks.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This fixes a gtk-doc complaint about the argument name not matching
what’s used in the gtk-doc comment.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It is a bug if we distribute files which are generated at build time —
they should be built on the machine which is compiling GLib, not be
shipped in the tarball.
This brings the autotools-generated tarball in line with the
ninja-generated one, with the exception of man pages and gtk-doc HTML
output.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If something which looks like a closing tag is left unfinished, but
isn’t paired to an opening tag in the document, the error handling code
would do a null pointer dereference. Avoid that, at the cost of
introducing a new translatable error message.
Includes a test case, courtesy of pdknsk.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1461
When formatting the error messages for markup parsing errors, the parser
was unconditionally reading a UTF-8 character from the input buffer —
but the buffer might end with a partial code sequence, resulting in
reading off the end of the buffer by up to three bytes.
Fix this and add a test case, courtesy of pdknsk.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1462
We should bail when we detect that adding a number of items to an array
would cause it to overflow. Since we can't change to using gsize for ABI
reasons we should protect the integrity of the process even if that means
crashing.
These tests will work if the glibc translations are up to date, or if
the GLib translations are installed and up to date; but not if neither
are in place.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
https://gitlab.gnome.org/GNOME/glib/issues/1447
Type punning is used on the existing implementation, which hides errors
such as:
GSList *list = NULL;
g_clear_pointer (&list, g_error_free);
Let's use __typeof__ to cast the passed-in pointer before it's passed to
the free function so it trips -Wincompatible-pointer-types if it's wrong.
Fixes#1425
PEP8 says that:
"Comparisons to singletons like None should always be done with is or
is not, never the equality operators."
glib uses a mix of "== None" and "is None". This patch changes all
cases to the latter.
If G_DISABLE_ASSERT is defined, g_assert() is a no-op. Despite it now
being standard practice to *not* use g_assert() in unit tests (use
g_assert_*() instead), a lot of existing unit tests still use it.
Compiling those tests with G_DISABLE_ASSERT would make them silently
no-ops. Avoid that by warning the user loudly.
Note that it’s pretty rare for people to compile with G_DISABLE_ASSERT,
so it’s not expected that this will be hit often.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/976
g_assert() must not be used in tests. g_assert_*() must not be used in
production code.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/976
If the fileutils test was run in a directory which is a symlink (for
example, on macOS, /tmp is often a symlink to /private/tmp), a path
comparison was failing. Compare the paths as inodes instead.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/889
Type punning is used on the existing implementation, which hides errors
such as:
GSList *list = NULL;
g_clear_pointer (&list, g_error_free);
Let's use __typeof__ to cast the passed-in pointer before it's passed to
the free function so it trips -Wincompatible-pointer-types if it's wrong.
Fixes#1425
When compiling third-party projects with -Wbad-function-cast, the inline
g_atomic_pointer_get() implementation which uses C11 __atomic_load*()
calls on GCC was causing compilation errors like:
error: cast from function call of type ‘long unsigned int’ to non-matching type ‘void *’
While we don’t want to compile all of GLib with -Wbad-function-cast, we
should support its headers being included in projects which do enable
that warning.
It doesn’t seem to be possible to cast away the warning (e.g. by casting
the function’s result through (void)), so we have to assign to an
intermediate integer of the right size first.
The same has to be done for the bool return value from
__sync_bool_compare_and_swap(). In that case, casting from bool to
gboolean raises a -Wbad-function-cast warning, since gboolean is
secretly int.
The atomic tests have been modified to enable -Wbad-function-cast to
catch regressions of this in future. The GLib build has conversely been
modified to set -Wno-bad-function-cast, just in case people have it set
in their environment CFLAGS.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1041
A lot of GLib APIs provide a string length and explicitly say that the strings
are not NUL terminated. For instance, parsing XML using GMarkupParser or
reading packed binary strings from mmapped data files.
Use either g_get_real_time() or g_date_time_new_now_local(). This means
we don’t need to worry about time_t being 32b in future (the year 2038
problem), and it makes the need for error handling a bit more explicit.
Improve the error handling in several cases.
Based on a patch by Niels De Graef
(https://gitlab.gnome.org/GNOME/glib/merge_requests/142).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1402
The accepted behaviour for reference counting functions can be described
as such:
- acquire: takes a pointer to a memory area and returns the same
pointer with its reference count increased; this means that the
returned value's ownership is fully transfered from the callee
to the caller
- release: takes a pointer to a memory area and drops the reference
count; this means that the caller transfers the ownership of the
argument to the callee
These annotations are mostly meant for documentation purposes: high
level language bindings are unlikely to use them, as they have their own
reference counting semantics on top of GLib's own, and they should not
expose this API to their own consumers.
The global hash table we use for interned strings should not own a
reference on the strings themselves, as otherwise we'd leak them all
over the place.
Instead, it should keep a "weak" reference to them; once the last
strong reference goes away, we drop remove the weak reference from the
hash table.
Both g_rc_box_release_full() and g_atomic_rc_box_release_full() should
allow passing NULL as the clear function, to conform to the existing
coding practices in GLib.
Additionally, this allows us to reimplement release() in terms of
release_full(), and improve test coverage.
The last part of the reference counting saga.
Now that we have:
- reference counter types
- reference counted allocations
we can finally add reference counted strings using reference counted
allocations to avoid creating a new String type, and reimplementing
every single string-based API.
It's more useful to have a dup() function that copies any blob of memory
into a reference counted allocation, than to have a dup() that only
copies a reference counted allocation.
GArcBox is the atomic reference counting version of GRcBox. Unlike
GRcBox, the reference acquisition and release on GArcBox are guaranteed
to be atomic, and thus they can be performed from different threads.
This is similar to Rust's Arc<Box<T>> combination of traits.
It is useful to provide a "reference counted allocation" API that can
add reference counting semantics to any memory allocation. This allows
turning data structures that usually are placed on the stack into memory
that can be placed on the heap without:
- adding a public reference count field
- implementing copy/free semantics
This mechanism is similar to Rust's Rc<Box<T>> combination of traits,
and uses a Valgrind-friendly overallocation mechanism to store the
reference count into a private data segment, like we do with GObject's
private instance data.
They’re all 8 bytes long, and integer constants that large need a suffix
on 32-bit platforms.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/977
Philip Withnall suggests that glib should treat all negative
file descriptors as unset/invalid, rather than explicitly requiring
them to be -1.
This can simplify the logic for some users of this code.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/132
It’s been de-facto deprecated for a long time, due to emitting a
critical warning when used in a non-internal context. Make that official
in the documentation and with a deprecation annotation.
Split the implementation into an internal helper and an external
wrapper, so the two remaining internal uses don’t emit deprecation
warnings.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/903
For the purposes of debugging, it is quite useful for every GSource to
have a name set. Ensure that any GSource we construct inside GLib has a
name set. For GSources which are then returned to the caller, this name
can then be overridden with something even more useful by the caller.
Since this data is only used for debugging, avoid doing any allocations
for it; just use static strings.
https://gitlab.gnome.org/GNOME/glib/issues/1175
It’s good to know *which* GMainContext is used to determine the ID, and
the preconditions for calling this method.
Using wording suggested by Emmanuele Bassi <ebassi@gmail.com>.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Function do_posix_spawn uses environ, but gspawn.c doesn't declare it.
Since there is no system header declaring this global variable, this
causes compilation error on FreeBSD.
Code added in this commit is copied from genviron.c.
G_SPAWN_LEAVE_DESCRIPTORS_OPEN must be set to enable the optimized
posix_spawn codepath, so this flag is likely to see more usage now.
Document that FD_CLOEXEC can be used to cause file descriptors to be
automatically closed while this flag is used.
When the amount of free memory on the system is somewhat low, gnome-shell
will sometimes fail to launch apps, reporting the error:
fork(): Cannot allocate memory
fork() is failing here because while cloning the process virtual address
space, Linux worries that the thread being forked may end up COWing the
entire address space of the parent process (gnome-shell, which is
memory-hungry), and there is not enough free memory to permit that to
happen.
In this case we are simply calling fork() in order to quickly call exec(),
which will throw away the entirity of the duplicated VM, so we should
look for ways to avoid the overcommit check.
The well known solution to this is to use clone(CLONE_VM) or vfork(), which
completely avoids creating a new memory address space for the child.
However, that comes with a bunch of caveats and complications:
https://gist.github.com/nicowilliams/a8a07b0fc75df05f684c23c18d7db234https://ewontfix.com/7/
In 2016, glibc's posix_spawn() was rewritten to use this approach
while also resolving the concerns.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=9ff72da471a509a8c19791efe469f47fa6977410
I experimented with a similar approach in glib, but it was not practical
because glibc has several items of important internal knowledge (such as
knowing which signals should be given special treatment because they are
NPTL implementation details) that are not cleanly exposed elsewhere.
Instead, this patch adapts the gspawn code to use posix_spawn() where
possible, which will reap the benefits of that implementation.
The posix_spawn API is more limited than the gspawn API though,
partly due to natural limitations of using CLONE_VM, so the posix_spawn
path is added as a separate codepath which is only executed when the
conditions are right. Callers such as gnome-shell will have to be modified
to meet these conditions, such as not having a child_setup function.
In addition to allowing for the gnome-shell "Cannot allocate memory"
failure to be avoided, this should result in a general speedup in this
area, because fork()'s behaviour of cloning the entire VM space
has a cost which is now avoided. posix_spawn() has also recently
been optimized on OpenSolaris as the most performant way to spawn
a child process.
Add a new process spawning function variant which allows the caller
to pass specific file descriptors for stdin, stdout and stderr.
It is otherwise identical to g_spawn_async_with_pipes.
Allow the same fd to be passed in multiple parameters. To make this
workable, the child process logic that closes the fd after the first time
it has been dup2'ed needed tweaking; we now just set those fds to be
closed upon exec using the CLOEXEC flag. Add a test for this case.
This will be used by gnome-shell to avoid performing equivalent
dup2 actions in a child_setup function. Dropping use of child_setup will
enable use of an upcoming optimized process spawning codepath.
Nevertheless it accepts "w+b".
When checking the Win32 documentation of fopen()/_wfopen(), it clearly
states:
> In addition to the earlier values, the following characters can be
> appended to mode to specify the translation mode for newline
> characters.
This implementation expects 'b' or 't' to be appended, and therefore
"wb+" ends up with an error, whereas the alias "w+b" works perfectly
while it is exactly the same thing. So let's just have glib "translate"
the mode when it can to have it working transparently the same way on
every platform.
Using g_assert_cmpfloat() with a float or double causes warnings on the
newest Clang version, because the macro internally promotes all values to
a long double, which Clang warns about. Casting explicitly removes the
warning.
Closes: #1377
This commit adds two W32-only environmental variable checks:
* G_WIN32_ALLOC_CONSOLE, if set to 1, will force glib to create
a new console if the process has no console by itself.
This option is for GUI apps that are launched from GUI
processes, in which case there's no console anywhere near them.
* G_WIN32_ATTACH_CONSOLE, if set to a comma-separated list of
standard stream names (stdint, stdout, stderr), will reopen
a given std stream and tie it to the console (using existing console
or parent console).
This works either with the other option (to create a console),
or if the app is launched from a console process (often the
case for developers).
The redirection is done with freopen(), dup() and dup2().
If everything goes well, C file descriptors 0, 1 or 2 will
be bound to stdin, stdout and stderr respectively (only for
streams listed in the envrionmental variable), and so will
be stdio streams by the same names.
With these it's possible to see the output of g_log*() functions
when running GTK4 applications, which are linked as GUI applications,
and thus do not get a console by default.
https://bugzilla.gnome.org/show_bug.cgi?id=790857
Fixes issue #1304
This function only calls fsync() if @target exists and is non-empty. If
not, it doesn't provide the "old contents or new contents" guarantee
that one might expect. This has been the case since
d20a188b12, and is justified either as a
performance optimization or by asserting that this function only
guarantees to not destroy existing data (implicitly defining
non-existence or emptiness as not data).
In addition, explicitly spell out that whether it's atomic in the
non-empty case is system-dependent. If the system administrator has
configured some funky filesystem options, they may be out of luck on the
atomicity front.
https://gitlab.gnome.org/GNOME/glib/issues/1302
This fits better with the convention in the rest of GLib where arbitrary
8-bit values are represented as guint8, avoiding the potential confusing
of a name which references ‘char’s.
This is not an API break, as both guint8 and guchar are unconditionally
typedeffed to unsigned char.
https://gitlab.gnome.org/GNOME/glib/issues/896
People do (and should) use g_str_equal() for string comparisons outside
of hash tables, because it’s easier to read than
`strcmp (str1, str2) == 0`. That should not be discouraged.
However, we should still be careful to point out that g_str_equal() is
not NULL-safe, and g_strcmp0() is.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
A slightly modified patch originally written by Morten Welinder
<terra@gnome.org> to make the error codes returned by g_spawn_*()
functions more specific when on Windows. They are already this specific
on Linux.
Add a unit test for the ENOENT case.
https://gitlab.gnome.org/GNOME/glib/issues/303
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The error number was saved after some g_debug() and g_free() calls, in
various places, which meant it could have been overwritten since the
error we care about happened.
https://gitlab.gnome.org/GNOME/glib/issues/303
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This allows test calls to produce output with \n
line separators on Windows, instead of \r\n.
Reduces the number of ifdefs, since all checks
can be done against one template on all platforms.
Test that the API behaves as expected, especially when we get to
saturation.
Additionally, check that both the function and the macro versions of the
API behave identically.
If we're using GCC we can use __extension__ to inline the grefcount and
gatomicrefcount API, and avoid the function call.
These macros are only enabled if G_DISABLE_CHECKS is defined, as they
remove critical warnings when the reference counters achieve saturation.
We have a common pattern for reference counting in GLib, but we always
implement it with ad hoc code. This is a good chance at trying to
standardise the implementation and make it public, so that other code
using GLib can take advantage of shared behaviour and semantics.
Instead of simply taking an integer variable, we should create type
aliases, to immediately distinguish the reference counting semantics of
the code; we can handle mixing atomic reference counting with a
non-atomic type (and vice versa) by using differently signed values for
the atomic and non-atomic cases.
The gatomicrefcount type is modelled on the Linux kernel refcount_t
type; the grefcount type is added to let single-threaded code bases to
avoid paying the price of atomic memory barriers on reference counting
operations.
Meson has the ability to classify tests according to "suites", a list of
tags. This is especially useful when we want to run specific sets of
tests — e.g. only GLib's tests — instead of the whole test suite. It
also allows us to classify special tests, like "slow" ones, so that we
can only run them when needed.
In master, it is already possible to build GLib using Visual Studio
using Meson[1] for some time, so we should focus on maintaining only the
Meson build files for building GLib with Visual Studio.
[1]: There are caveats when building with Visual Studio 2008, namely
that one needs to use the mt command to embed the manifests that
are generated with the .exe/DLLs, for all builds, and that in the
case where the compilation hangs on Visual Studio 2008 x64, as a
workaround, should stop the build by terminating all cl.exe tasks
and change the compiler optimization flag from /O2 (full speed) to
/O1 (optimize for size), due to compiler optimization issues.
When over-allocating by inserting values off the end of an array, maybe
expand the array once, rather than twice (once for setting the size and
once for appending the values).
Suggestion by Peter Bloomfield (@peterb) as a follow-up to #1374.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Previously, there was very little coverage of GArray behaviour with
either of the zero_terminated or clear_ arguments to g_array_new() set
to TRUE.
Parameterise the tests and exhaustively expand the coverage to cover all
possible GArray configurations.
This was made possible by the online code coverage report for GLib which
we now have:
https://gnome.pages.gitlab.gnome.org/glib/coverage/glib/garray.c.gcov.html.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795975
Previously, g_array_insert_vals() would crash if called with an index
off the end of the array. This is inconsistent with the behaviour of
other methods (like g_array_set_size()), which will expand the array as
necessary.
Modify g_array_insert_vals() to expand the array as necessary. New array
elements will be cleared to zero if the GArray was constructed with
(clear_ == TRUE).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795975
They do both accept NULL value arrays, but only if the number of
elements in the value array is zero. Fix the annotations and mention
this in the documentation.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795975
It's mostly not used anymore and doesn't do what it says it does.
The docs state that it affects GList, GSList, GNode, GMemChunks, GSignal,
GType n_preallocs and GBSearchArray while:
* GList, GSList and GNode use GSlice and are not affected
* GMemChunks is gone
* GType npreallocs is ignored
It also states that it can be used to force the usage of g_malloc/g_free,
which is handled by G_SLICE=always-malloc now.
The only places where it's used is in signal handling through GBSearchArray
and in GValueArray (deprecated). Since it's unlikely that anyone wants to
reduce allocation sizes just for those cases remove the build option.
See commit 4c2928a544 for why checking AT_SECURE is preferable compared
to UID checks as currently done in the fallback case.
getauxval() was added with glibc 2.16
While glibc <2.19 didn't provide a way to differentiate a 0 return value from an error,
passing AT_SECURE should always succeed according to
https://sourceware.org/ml/libc-alpha/2014-07/msg00407.html
I've added an errno check anyway, to be on the safe side.
It was added in 4c2928a544 to potentially enable accessing
AT_SECURE through __libc_enable_secure, but was never enabled.
Newer glibc provides getauxval(AT_SECURE) which should be used instead.
Add a TODO note for that.
ENABLE_GC_FRIENDLY_DEFAULT was supposed to set the default for the gc friendliness
while still allowing to force enable it at runtime with G_DEBUG=gc-friendly.
With commit 943a18b564 (6 years ago) things were changed to always set it
according to the content of G_DEBUG in glib_init(), making the default unused.
Since nobody complained since then just remove the macro and the build option.
g_date_strftime() on Windows uses the SYSTEMTIME structure which requires the
year to be >=1601. Passing 1 results in a negative SYSTEMTIME.wYear
which makes GetDateFormatW() fail and crashes due to missing error handling.
Just use 1976 as that's already used a few lines down.
Add a test macro that allows comparing two floating point values for
equality within a certain tolerance.
This macro has been independently reimplemented by various projects:
* Clutter
* Graphene
* colord
https://gitlab.gnome.org/GNOME/glib/issues/914
valgrind.h is a verbatim copy taken from Valgrind project. Previously
that file had local changes that got dropped by last update. To avoid
regressing again, do not edit valgrind.h anymore and instead add a
gvalgrind.h wrapper that gets included instead.
This fix 2 errors:
- uintptr_t is not defined when including valgrind.h on mingw.
- MSVC compiler is not supported on amd64-Win64 platform.
Better not modify copy/paster files otherwise this will regress again
later. It's better to not include valgrind.h at all when using MSVC.
This reverts commit bbcce75d4e.
The tests in test_async_queue_timed() assume that g_async_queue_timeout_pop()
and in turn g_cond_wait_until() wait at least until end_time
before returning, i.e. calling g_get_monotonic_time() after the timeout should result
in a value equal or larger than the timeout end time.
For the win32 implementation of g_cond_wait_until() this isn't the case which
makes those tests fail.
There are three reasons why the function returns early:
1) The underlying API works with milliseconds and the timeout gets rounded
down, resulting in a too small timeout value.
2) In case the timeout is too large to be passed to the API it gets limited
(there is also a bug because it converts INFINITE to milliseconds while
they already are, but using INFINITE would be wrong as well, as passing
a large timeout is not the same as blocking forever really)
3) Even with the rounding changed the underlying API still returns a bit early
sometimes on my machine (relative to g_get_monotonic_time())
This changes the implementation to round up to the next millisecond (fixing 1)
and to wait again in case a timeout occurs but the end time hasn't been
reached yet (fixing 2 and 3).
This makes the test_async_queue_timed() tests pass.
https://bugzilla.gnome.org/show_bug.cgi?id=795569
The timer tests expect that a small value for sleep does not result in
no sleep at all. Round up to the next millisecond to bring it more in line
with other platforms.
This fixes the glib/timer tests.
This makes the 'threadtests' time out since that uses small usleeps a lot and
until now didn't wait at all, but now always waits a msec. Reduce the amount
of tests done on Windows to get the runtime down to something reasonable again.
https://bugzilla.gnome.org/show_bug.cgi?id=795569
For g_autolist and g_autoslist, the cleanup func was cast to
GDestroyNotify before being passed to g_(s)list_free_full. This cast
provokes GCC 8 to emit a warning if the return type is not void:
…/gmacros.h:462:99: warning: cast between incompatible function types
from … to 'void (*)(void *)' [-Wcast-function-type]
Cast to 'void (*)(void)' first, which suppresses the warning as
recommended by the GCC documentation. g_autoptr remains untouched.
Fixes https://gitlab.gnome.org/GNOME/glib/issues/1382
In commit f49a93b207
from bug https://bugzilla.gnome.org/show_bug.cgi?id=791342
we added two new static inline cleanup helpers in case a type was
used inside a list.
These functions will commonly be unused.
In rpm-ostree, we run a build using `CC=clang -Werror=unused` because
it catches `g_autofree char *foo = NULL;` as unused, but GCC doesn't.
When trying to update to F28 with a newer glib, our CI fell over on this.
Mark all of the autocleanups as "maybe unused".
Visual Studio x64 builds do not allow inline assembly code, so we need
to re-add the code that disables inline assembly when we build with
Visual Studio for x64 builds, as we did before. This is necessary when
we update the included valgrind.h.
The output of the %p type is implementation defined and on Windows we get
leading zeros depending on the pointer type size. Instead of adding
ifdeffery use g_snprintf() to generate the expected message.
https://bugzilla.gnome.org/show_bug.cgi?id=795569
g_steal_pointer is both an inline function, returning gpointer, and a
macro that casts the return value to the type of its argument. The first
version of the macro uses '0 ? (*(pp)) : (g_steal_pointer) (pp)' to cast
the return value to the type of *pp, but this fails to yield warnings
about incompatible pointer types with current gcc. Apparently the
ternary operator is optimized away before the type of the expression is
determined.
The typeof() (or __typeof__()) operator allows an explicit cast.
https://bugzilla.gnome.org/show_bug.cgi?id=742456https://bugzilla.gnome.org/show_bug.cgi?id=796341
Previous version of this function started with a call to g_utf8_to_utf16(),
which also served as a NULL check, since g_utf8_to_utf16() just returns NULL
on NULL strings. Current version of this function does some filename string
checks first and converts it to utf16 only after these checks are done, and
these checks do not take into account the possibility of filename being NULL.
Fix this by explicitly checking for NULL.
The current docs implied, by using the printf name, that the macros would
be compatible with printf(), but that's not always the case.
On Windows we use gnulib if the system printf isn't good enough.
This can happen on MinGW without __USE_MINGW_ANSI_STDIO set or with MSVC
with a varrying degree of incompatibility.
https://bugzilla.gnome.org/show_bug.cgi?id=795569
This allows building with posix threads on Windows. It is generally
better to use win32 threads implementation on Windows, but this option
can be used in case it causes issues, or for performance comparison for
example.
https://bugzilla.gnome.org/show_bug.cgi?id=784995
win32_cflags gets used globally as cflags and exposed in the .pc file.
win32_ldflags gets passed to glib-2.0 and exposed in the .pc file.
This should match what the autotools build is currently doing with
GLIB_EXTRA_CFLAGS and G_LIBS_EXTRA.
https://bugzilla.gnome.org/show_bug.cgi?id=784995
• A leak of filename on an error path
• A leak of resolved_identifier if no out_identifier return location
was provided
The latter was spotted by Peter Bloomfield
(8945227743 (note_111254)).
Thanks!
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
__MINGW32__ is defined on all MinGW variants including MinGW-w64.
__MINGW64_VERSION_MAJOR is only defined on MinGW-w64.
This difference is important because on MinGW-w64 we must #include
winternl.h because including ntdef.h results in compiler errors
about symbol redefinition, and the header warns that it is deprecated
and may be removed in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=795849
On non-glibc platforms gettext is provided by extra libintl dependency.
We wrongly thought libintl is an internal dependency and applications
needs to explicitly link on it, but turns out that breaks many
applications and with autotools the .pc generated actually has -lintl in
public "Libs:".
https://bugzilla.gnome.org/show_bug.cgi?id=796085
These make it easy to steal elements from pointer arrays without having
the array’s GDestroyNotify called on them, similarly to what’s possible
with g_hash_table_steal().
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795376
If using g_ptr_array_remove*() with a non-NULL GDestroyNotify function,
the value returned will probably be freed memory (depending on what the
GDestroyNotify) function actually does. Warn about that in the
documentation. We can’t just unconditionally return NULL in these cases,
though, since the user might have set the GDestroyNotify to a nifty
function which doesn’t actually free the element; so returning it might
still be valid and useful.
Also add missing (nullable) annotations to that documentation.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795376
They were almost identically the same. This introduces no functional
changes, but will help with upcoming additions to GPtrArray.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795376
-z nodelete breaks the libresourceplugin module usage in the resources.c
test, which expects to be able to unload it.
Make the Meson build match what the autotools build does: only pass
glib_link_flags to the headline libraries (glib-2.0, gio-2.0,
gobject-2.0, gthread-2.0, gmodule-2.0) and omit it from all other build
targets.
https://bugzilla.gnome.org/show_bug.cgi?id=788771
This is a combination of g_hash_table_lookup_extended() and
g_hash_table_steal(), so that users can combine the two to reduce code
and eliminate a pointless second hash table lookup by
g_hash_table_steal().
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795302
Update our copy of valgrind.h from the Valgrind 3.13 release tarball.
This seems to include fixes for PPC and Solaris. No changes made to the
header file.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=736741
Make it a bit clearer that all lengths passed to GRegex methods are in
bytes (not characters). This is mentioned in the section overview, but
who reads that?
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=748620
On Windows we use gnulib and elsewhere we use glibc or similar.
Also change G_GNUC_PRINTF to use gnu_printf instead of __format__ if
possible because __format__ evaluates to ms_printf under MinGW,
but we use gnulib there and not the system printf.
gnu_printf is only available with GCC>=4.4 and not with clang.
https://bugzilla.gnome.org/show_bug.cgi?id=795569
The timezone setup utility of FreeBSD, tzsetup, which is run during the
installation, creates /etc/localtime by copying the chosen timezone file
from /usr/share/zoneinfo. Although it can correctly deal with the case
where /etc/localtime is a symlink, it is not the default and there is no
user interface to change the default copying behaviour.
Fortunately, tzsetup has been modified to write the name of the chosen
timezone to /var/db/zoneinfo in 2009, so we can know the name of the
current timezone by reading it. DragonflyBSD also seems to do the same
thing in its tzsetup.
https://svnweb.freebsd.org/changeset/base/198267https://bugzilla.gnome.org/show_bug.cgi?id=795165
It seems that the test expects g_date_time_format to return formatted
results in English, and there is no setlocale (LC_ALL, "") call in the
file so the test does run in the default C locale. However, gettext
seems to read the value of LC_MESSAGES from the environment by itself.
Even if the value of LC_MESSAGES locale is C because of not calling
setlocale, gettext still translates the name of the month according to
the LC_MESSAGES environment variable, causing g_date_time_format_locale
to fail on the "%b" test case because it cannot convert UTF-8 text
returned by get_month_name_with_day to ASCII.
To avoid the test failure, we set the LC_MESSAGES environment variable
to C before format tests and restore it at the end of the function.
https://bugzilla.gnome.org/show_bug.cgi?id=795165
The return value of g_file_read_link ("/etc/localtime") can
be a relative path in the form of "../usr/share/zoneinfo".
This breaks the prefix check that is performed, and makes
the timezone identifier be "../usr/share/zoneinfo/America/Sao_Paulo",
for example, which breaks other parts of the system.
Fix that by canonicalizing the symlink path if we detect
is it a relative path.
(Tweaked by Philip Withnall <withnall@endlessm.com> to remove a
conditional which was unnecessary.)
https://bugzilla.gnome.org/show_bug.cgi?id=111848
Getting the canonical filename is a relatively common
operation when dealing with symbolic links.
This commit exposes GLocalFile's implementation of a
filename canonicalizer function, with a few additions
to make it more useful for consumers of it.
Instead of always assuming g_get_current_dir(), the
exposed function allows passing it as an additional
parameter.
This will be used to fix the GTimeZone code to retrieve
the local timezone from a zoneinfo symlink.
(Tweaked by Philip Withnall <withnall@endlessm.com> to drop g_autofree
usage and add some additional tests.)
https://bugzilla.gnome.org/show_bug.cgi?id=111848
All those logging functions already add a newline to any message they
print, so there’s no need to add a trailing newline in the message
passed to them.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
This continues one of the const-correctness fixes from the previous
commit (it needed some more transitive fixes), and reverts another of
them, since it was over-zealous.
This fixes CI failure: https://gitlab.gnome.org/GNOME/glib/-/jobs/27125.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
Spotted when temporarily compiling with -Wwrite-strings. This only goes
a small way towards making the code base -Wwrite-strings–clean. It
introduces no functional changes, and fixes no bugs.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
If g_get_home_dir() calculated a NULL home directory (due to $HOME being
unset and /etc/passwd being inaccessible, for example due to an
overly-zealous LSM), it would call g_once_init_leave (&home_dir, NULL),
which would emit a critical and fail to leave the GOnce critical
section. That meant that the following call to g_get_home_dir() would
deadlock in g_once_init_enter().
Fix that by setting the home directory to a made-up value in such cases
(which the documentation handily already explicitly allows).
Thanks to Simon McVittie for the analysis leading to an easy patch.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=773435
Fix various warnings regarding unused variables, duplicated
branches etc by adjusting the ifdeffery and some missing casts.
gnulib triggers -Wduplicated-branches in one of the copied files,
disable as that just makes updating the code harder.
The warning indicating missing features are made none fatal through
pragmas. They still show but don't abort the build.
https://bugzilla.gnome.org/show_bug.cgi?id=793729
glib enables -Werror=format-nonliteral by default which is triggered
by the embedded gnulib (in vasnprintf.c). Disable that warning
for gnulib alone. The gnulib code is there to handle user provided
format strings, so the warning doesn't add anything anyway.
This fixes the build under MinGW.
https://bugzilla.gnome.org/show_bug.cgi?id=793729
For a long time we've had it as 'common knowledge' that criticals are
for programmer errors and warnings are for external errors, but we've
never documented that. Do so.
(Modified by Philip Withnall <withnall@endlessm.com> to apply cleanly to
master; rearranged to fit in with current master documentation.)
https://bugzilla.gnome.org/show_bug.cgi?id=741049
And warn in other parts of the code if the caller attempts
to change the array bounds during destruction, this is not
a valid operation.
(Tweaked by Philip Withnall <withnall@endlessm.com> to not use inline
for loop declarations, since we can’t support them in GLib at the
moment.)
https://bugzilla.gnome.org/show_bug.cgi?id=769064
The tests which check permissions and errors like EACCES aren’t going to
work as root, since root always has permission to do things. Skip them
if running as root.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=766390
Make it more obvious that an explicit check isn’t needed for the upper
bound on years, since it’s limited by the type width.
Add a unit test to demonstrate this.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=540013
GDate.dmy is a 1-bit bitfield which is treated as a boolean. However,
it’s still an integer, and we can’t really treat it like a gboolean
because it’s a bitfield. Make the comparisons with it explicitly compare
integers, rather than implicitly, to make it more obvious that it is
actually an integer.
This introduces no functional changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=335731
These turn undefined or hard-to-detect misbehaviour into a well-defined
critical warning and early return.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=335731
It’s possible to get a -Wmaybe-uninitialized warning out of this code
with some GCC versions. Rework the code to avoid needing the conditional
free.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=728108
This was a small leak of a GDateTime instance from an internal helper
function, which was using it to calculate week numbers, and then forgot
to free it.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795165
This is a non-trivial accessor which gets the identifier string used to
create the GTimeZone — unless the string passed to g_time_zone_new() was
invalid, in which case the identifier will be `UTC`.
Implementing this required reworking how timezone information was loaded
so that the tz->name is always set at the same time as tz->t_info, so
they are in sync. Previously, the tz->name was unconditionally set to
whatever was passed to g_time_zone_new(), and then not updated if the
tz->t_info was eventually set to the default UTC information.
This includes tests for the new g_time_zone_get_identifier() API, and
for the g_date_time_get_timezone() API added in the previous commit.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795165
gdatetime testcase uses glib (which uses libintl), but *alsi* calls
libintl functions on its own, as part of the testing process.
Therefore it must be linked to libintl like any other program that
uses it.
https://bugzilla.gnome.org/show_bug.cgi?id=794556
We do not need to use FindFirstFileW() to get a reparse tag if the
file that is being examined is not a reparse point.
This is a quick and relatively painless fix for the fact that
FindFirstFileW() fails on root directories. Since root directories
are unlikely to be reparse points (is it even possible?), not using
this function on non-reparse-points just sidesteps the issue.
https://bugzilla.gnome.org/show_bug.cgi?id=795153
If a handle was obtained from a fd that we got from up the stack,
we shouldn't call CloseHandle() on it in case of an error.
This is a bug. Luckily, it happens only on the error codepath, so,
hopefully, no one had hit it yet.
Accurate G_HAVE_GNUC_VISIBILITY is needed to correctly
define G_GNUC_INTERNAL later on. Autotools did that,
meson currently doesn't and opts to just set
G_HAVE_GNUC_VISIBILITY to 1 for all compilers except MSVC.
This leads to MinGW GCC having G_HAVE_GNUC_VISIBILITY=1,
which results in G_GNUC_INTERNAL being defined to
__attribute__((visibility("hidden"))), which is not supported.
Because cc.compiles() does not support override_options or
anything like that, we just feed it '-Werror' as-is, since
MSVC is known as not supporting visibility attributes anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=794636
This pollutes the reserved compiler namespace and breaks applications
trying to do their own feature detection. For instance, this falsely
detects that alloca is not a builtin on gcc:
#include <glib.h>
#if defined(__has_builtin)
# if !__has_builtin(alloca)
# error "wtf glib?"
# endif
#else
/* version-checking to determine alloca existence */
#endif
Instead, define our own g_macro__has_* versions that have the
behaviour that we need.
https://bugzilla.gnome.org/show_bug.cgi?id=794635
date.c uses SUBLANG_LITHUANIAN_LITHUANIA which is Vista+
Include config.h so that _WIN32_WINNT is defined and the newer macros
are exposed.
This fixes the build under MinGW.
https://bugzilla.gnome.org/show_bug.cgi?id=793729
This patch relaxes the comparison rules and allow the month names to be
in a mixed case.
Translators should be allowed to provide the month names in a different
case (lower/upper case, not grammatical case) from the content of glibc
because it is disputable at the moment whether the month names should
follow the language rules strictly and be titlecased only if it is
obligatory to titlecase them or they should be also titlecased in the
standalone case. Hopefully in future a conversion specifier will be
invented to control the upper/lower case individually.
https://bugzilla.gnome.org/show_bug.cgi?id=793645
