We’re trying to eliminate the legacy `tests/` directory. This commit
moves the code from `tests/iochannel-test.c` into
`glib/tests/io-channel.c` and ports it to the latest GLib test coding
standards:
* Change `g_assert()` to `g_assert_*()`
* Print verbose messages with `g_test_message()`
* Rename some variables to conform to modern conventions
* Use `GTest`
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1434
This adds gi_type_tag_argument_from_hash_pointer() and
gi_type_tag_hash_pointer_from_argument(). They do the same thing as
the corresponding g_type_info_... functions, which are used to pack and
unpack the correct field of a GIArgument into/from a data pointer in
GHashTable or GList, regardless of machine architecture or endianness.
These functions take a GITypeTag obtained from
g_type_info_get_storage_type(), instead of a GITypeInfo pointer. (The
storage type is the only piece of data that is actually used from the
GITypeInfo structure.)
It's intended for bindings using an argument cache, such as GJS and
PyGObject, so that they don't have to store a whole 64-bit GITypeInfo
pointer in their cache in many common cases, and can just store the 5-bit
type tag instead.
The original g_type_info_... functions are reimplemented in
terms of the new g_type_tag... functions.
We are matching `<parameter>` as well as `<para>`, and we
end up with broken XML in case the (expanded) description
starts with `<parameter>`.
Fixes: #2601
We can't exercise precondition check failures if GLib was (inadvisably)
compiled with -Dglib_checks=false, and we shouldn't necessarily exercise
precondition check failures when using QA tools like valgrind, so skip
these tests if run with -m no-undefined.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously, these tests would always pass. If the precondition check
failed (as we want it to), the subprocess would exit unsuccessfully;
but if the precondition check wrongly passed, the subprocess would
continue, allocate a nonzero amount of memory, and fail the
g_assert_null(), resulting in the subprocess exiting unsuccessfully
and the test still passing.
Signed-off-by: Simon McVittie <smcv@collabora.com>
On ILP32 platforms, 4 is a valid alignment for g_aligned_alloc(), so
use 2 as our invalid alignment instead.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This allows the controller to explicitly be removed from the bus, in a
way that allows the caller to synchronise with it and know that all
other references to the controller should have been dropped (i.e. after
this method returns, there should be no in-flight D-Bus calls still
holding a reference to the object).
This is needed to be able to guarantee finalisation of the controller in
unit tests (and comparable real-world situations).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1190
The resources data is generated for both GCC and MSVC toolchains, even
though we know beforehand which toolchain we're going to compile it for.
By dropping the data duplication we make the generated resources file
faster to compile, especially when dealing with large embedded data,
instead of relying on the C pre-processor to walk the whole file and
discard the branch we're not using.
We only want to include gslist.h here if it was not already included via
including glib.h, as:
* gslist.h should normally be included via glib.h if used outside of
GLib itself.
* This broke Visual Studio builds that use GResources (via
glib-compile-resources.exe) as that would cause the generated code to
include gslist.h directly, which is therefore disallowed.
We can just update the for loop condition to be >0 for all builds, which
is actually equivilant to >=1 as we are essentially comparing an
unsigned 32-bit int, so that we don't need to worry about fixing the
VS2012 bug invasively, as Visual Studio 2012 x64 is more sensitive about
sizes of variables (e.g. pointer sizes in this case)
The __ia64 and __x86_64__ macros are defined for GCC but not Visual
Studio, but actually this code path should also be taken for Visual
Studio when doing a 64-bit build (x86_64/x64 and aarch64/arm64, _WIN64
will be defined for these cases), since Windows is an LLP64 platform.
This will avoid C4311/C4312 warnings on Visual Studio builds, which are
often warnings of concern as we are dealing with pointers with differing
sizes on 32-bit and 64-bit Windows builds.
Later GLib versions assume that warning C4715 is an error as we want ot
be sure that functions that return a value do indeed return one by all
means.
Avoid this warning by adding a 'return 0' in brz_search_packed(), it
might be pointless but does indeed avoid the warning.
