As a special case, keep the historical behaviour of treating gchar
as being signed, both on platforms where it is genuinely signed (for
example x86 Linux) and where it is unsigned (for example ARM, s390x
and PowerPC Linux). Changing gchar to use INTEGER_ALIAS would have a
regression risk, so if we want to do that, it should be as a separate
change.
No functional change intended.
Signed-off-by: Simon McVittie <smcv@debian.org>
It’s currently completely untested. Let’s add a few basic tests so that
adding more tests in future is easier.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
In macOS compilation fails with the following error:
```
In file included from ../girepository/tests/autoptr.c:23:
../girepository/girffi.h:30:10: fatal error: 'ffi.h' file not found
```
Relocation is a common scenario in macOS applications and frameworks.
This commit provides a mechanism to support relocations by inferring
the typelib dir from the path of the loaded image libgirepository-1.0.dylib.
For historical reasons, some doc blocks are included in an ancillary
file. Add it to the list of sources parsed by g-ir-scanner, to increase
the coverage of various macros.
Fixes: #3372
It's just better than a list of strings for various reasons, but mostly
here it allows also to avoid copying the lists but making the
ownership clearer through references
In this way the module can survive without that the parser is fully
alive.
At the moment a module has not a ref-count system, but this makes things
clearer when we return the module from a parser.
In case the node was pushed to a non-empty node stack, then we were not
tracking it in the entries list, and so nothing was freeing it on
destruction.
As per this, once parsing is done, we can free it or we'd leak.
The compiler code was full of leaks and nothing really checked on them.
While it's not a big deal per se, per the nature of it, it's still
better to ensure that memory management is well done so that there are
no problems when using it with sanitizers.
So, the source of the problems was not freeing the parser, but that
wasn't enough, more to come...
We are overriding the default g-ir-compiler for local usage, but this
is not actually happen since that's computed while parsing introspection
So generate the compiler as first thing, then in case handle the
introspection data
As with the previous two commits, the results of calling
`gi_repository_get_loaded_namespaces()` were previously
non-deterministic due to being generated by iterating over a hash table,
which has a non-deterministic iteration order.
Fix that by using the new `ordered_typelibs` and `ordered_lazy_typelibs`
arrays to provide deterministic ordering.
At the same time, significantly reduce the number of allocations needed
to build the return value — previously the results would be built as a
linked list before being turned into an array. The linked list is now
banished to history.
Add some more unit tests to maximise test coverage of this method.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3303
As with the previous commit, finding a `GIBaseInfo` matching the given
error domain was non-deterministic because it iterated through a hash
table of typelibs. Hash table iteration is non-deterministic.
Change the method to instead use the `ordered_typelibs` and
`ordered_lazy_typelibs` arrays to give deterministic iteration order.
Add a unit test, although it can’t test the interesting case of an error
domain which is present in both `GioUnix`/`GioWin32` and `Gio`, because
no such error domain exists.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3303
When faced with a `GType` which is present in multiple typelibs, the old
implementation was not deterministic, as it iterated over a hash table
of typelibs. The iteration order of a hash table is not deterministic.
Use the new `ordered_typelibs` and `ordered_lazy_typelibs` arrays to
iterate instead, making the order deterministic.
Add a unit test to check this. In particular, to check that symbols
which are present in both `Gio` and `GioUnix` are correctly resolved as
being from `GioUnix`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3303
The iteration code used `g_string_overwrite_len()` to try and simplify
buffer allocation and growth, but seemingly forgot to handle the fact
that it doesn’t nul-terminate what it overwrites: the method is intended
to be used to splice bits into longer strings, not to overwrite an
entire nul-terminated string.
This meant that when iterating over a comma-separated `c_prefix` like
`GUnix,G`, on the second iteration `g_string_overwrite_len()` would be
used to write `G` into index 0 of the already-set `GUnix` string in the
buffer, leading to the first iteration happening all over again and the
`G` prefix being ignored.
This led to symbols failing to be matched to the `GioUnix` typelib, even
though they should have been.
This will be checked by a test in the following commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3303
There are various places where the set of typelibs is iterated over or
returned in an ordered way. In order to keep results deterministic and
reproducible, we need to keep this set ordered.
Keep a `GPtrArray` of the typelibs (one for fully-loaded ones and one
for lazy ones) alongside the existing hash tables. This will be used for
iteration in the next few commits.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3303
The type used when declaring a bitfield member of a struct doesn't
affect the amount of space allocated for it - only whether it's signed
or unsigned. In standard C99 (6.2.7.1), only _Bool, signed int and
unsigned int or typedefs to them are allowed as bitfield types, but GCC
allows other integer types as an extension.
In this case, the GIBaseInfo and GIBaseInfoStack structs are meant to
have identical layout. However, type_is_embedded was declared as an
unsigned bitfield in the former and a uint32_t in the latter. This was
harmless on most platforms because the following member is an aligned
pointer, but (for example) on m68k-linux-gnu pointers only need to be
16-bit aligned, so GCC only allocates 16 bits for the bitfield.
Change the type in the declaration to unsigned int, and add an padding
bitfield following it to ensure there's space for 32 bits on all
platforms in the future.
Signed-off-by: Adam Sampson <ats@offog.org>
It's an array containing the list of sanitizers in use, normally it
contains a value, but in some cases may have more than one (e.g.
'address' and 'undefined').
And so use it to avoid repeated checks
Tests may have runtime dependencies that are related to the typelib
dependencies, so we need to satify them or the tests will fail at
runtime if we're not building their prerequisite for other reasons.
That's saying that the tests are currently failing when explicitly
running as standalone in meson.
Co-Authored-By: Philip Withnall <philip@tecnocode.co.uk>
It’s very obviously a false positive, as `str` has been added to on the
previous line, so can’t be `(void *) 0`. Not sure what scan-build is
thinking.
I’d rather not have this assertion (it doesn’t help the programmer’s
understanding of the code), but I would also rather have scan-build
running with no warnings so that it can helpfully catch newly-introduced
errors in future.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
Basically various trivial instances of the following MSVC compiler
warning:
```
../gio/gio-tool-set.c(50): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
There is a meson option (gir_dir_prefix), but without being passed in here
the files would always get installed into the default location (datadir).
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
All of the indications in the surrounding code are that `node` should
never be `NULL`, but the error handling for it did actually allow it to
be `NULL` iff its `parent` was also `NULL`.
That made scan-build (kind of legitimately) warn about `NULL` pointer
dereferences of `node`.
Avoid that by unambiguously using an assertion to prevent `NULL` nodes.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
scan-build thinks that the `atypes` array is leaked, but it’s not.
Ownership is transferred into the `ffi_cif` structure, and it’s
eventually freed in `gi_callable_info_destroy_closure()`.
Try and help the static analysis by adding an explicit ownership
transfer annotation. It probably won’t help.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
