This struct is only ever heap allocated, and enums are always the same
size as an int (or unsigned int), so it won’t change size.
The struct doesn’t correspond to any mmapped structure from a
typelib file.
This should fix some `-Wsign-conversion` warnings (curiously only seen
on the macOS CI runner) by using the most specific type.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
Due to passing around file lengths variously as `gsize` or `gssize`,
we can’t reliably handle files with length greater than `G_MAXSSIZE`, as
some of the APIs in use need `-1` to indicate that their input is nul
terminated.
Add some checks for this, and gracefully return an error if an input
file is too big, rather than just exploding.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
When parsing a GIR or building a typelib, stop setting the array length
field to `-1` as a default. That field is unsigned, so setting it to
`-1` is actually equivalent to setting it to `G_MAXUINT`. I can’t find
anywhere which treats `G_MAXUINT` or `-1` as a magic value there, so
it’s probably better off left unset.
Given the lack of documentation for the typelib code, though, there is a
fair chance I’m making a mistake and this is actually an integral part
of the format. Let’s see what breaks.
This fixes a `-Wsign-conversion` warning, at least.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
Reworking the code to add proper `GError` handling for type parsing,
rather than the existing `g_critical()`, turned out to actually be
fairly straightforward.
So now `gi_ir_parser_parse_string()` returns
`G_MARKUP_ERROR_INVALID_CONTENT` on unparseable types, just like it does
with various other bits of invalid GIR.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
If parsing a generic type which has no closing `>`, there was no check
that the `strchr()` call succeeded, which could have resulted in a
negative length being passed to `g_strndup()`, which would result in a
long positive length after implicit type casting.
Fix that by bringing an old error handling path back into use. This
results in a `g_critical()` in the calling function, which is good
enough for now. Potentially all this code could be reworked to use
`GError`, but that’s a much bigger project (a lot more of the
`girparser.c` code would need to change).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
There are a few `g_strndup()` calls which use a length calculated from
the return value of `strchr()` minus the original string. That’s fine,
as long as `strchr()` doesn’t return `NULL`. Add some asserts to ensure
that.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
As of gobject-introspection 1.83.2, a new `<doc:format name="…"/>`
element is supported (as a child of `<repository>`) in GIR files.
For the moment, this information isn’t needed in libgirepository — but
the GIR parser does have to know about the element in order to not throw
an error claiming it’s invalid.
This is a slightly tweaked version of the code added to
gobject-introspection.git in commit
9544cd6c962fab2c3203898779948309833e2439 by Corentin Noël
<corentin.noel@collabora.com>, reformatted slightly to fit in with
GLib’s style guidelines.
This is backwards compatible and does not require a new
gobject-introspection version.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3634
During "as-installed" testing, we should search the GIR_DIR for GIR XML,
instead of hard-coding that it is `${prefix}/share/gir-1.0`. This is
not the case on at least Debian, in order to make it possible to
install more than one architecture's flavour of `GLib-2.0.gir`,
which contains some architecture-specific `#define`s.
Also search GOBJECT_INTROSPECTION_DATADIR/GIR_SUFFIX (in practice
something like `/usr/share/gir-1.0` in all cases) to accommodate
distributions like Debian that move the architecture-independent
majority of GIR XML into /usr/share to avoid duplication, leaving
only the architecture-specific minority of files like `GLib-2.0.gir`
in the GIR_DIR.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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 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.
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
We don't actually need to use the Meson-detected size macros here,
because the result of `sizeof()` is an integer constant expression.
No functional change.
Signed-off-by: Simon McVittie <smcv@collabora.com>
g-ir-scanner currently maps these to lower-level types at scan time by
assuming that time_t is an alias for long, off_t is an alias for size_t
and so on. This is not always accurate: some ILP32 architectures have
64-bit time_t (for Y2038 compatibility) and 64-bit off_t (for large file
support), and that mismatch is tracked as GNOME/gobject-introspection#494.
One option for resolving this g-ir-scanner bug is to have it pass these
types through to the GIR XML, and teach g-ir-compiler and its replacement
gi-compile-repository to convert them to the corresponding concrete
type tag, as they already do for abstract types such as `long long` and
`size_t`.
Loosely based on GNOME/gobject-introspection!451 by Shuyu Liu.
Co-authored-by: Shuyu Liu <liushuyu011@gmail.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
We don't actually need to use the results of configure-time checks here:
sizeof is a perfectly reasonable integer constant expression, so we can
use that directly.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
Signed-off-by: Simon McVittie <smcv@collabora.com>
It seems cleaner to store this in the parser, rather than having the
compiler export a global variable that the parser must read.
Signed-off-by: Simon McVittie <smcv@collabora.com>
`GIIrNodeUnion` is built dynamically at runtime (rather than being
mmapped from disk), so its types can accurately reflect their runtime
semantics, rather than an on-disk format.
As part of this, switch from `atoi()` to `g_ascii_string_to_unsigned()`
for parsing the relevant fields from a GIR XML file. This means we now
get error handling for invalid integers.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
`GIIrNodeField` is built dynamically at runtime (rather than being
mmapped from disk), so its types can accurately reflect their runtime
semantics, rather than an on-disk format.
As part of this, switch from `atoi()` to `g_ascii_string_to_unsigned()`
for parsing the relevant fields from a GIR XML file. This means we now
get error handling for invalid integers.
This also includes some offset validity changes which were forgotten
from commit 515b3fc1dc.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
`GIIrNodeVFunc` is built dynamically at runtime (rather than being
mmapped from disk), so its types can accurately reflect their runtime
semantics, rather than an on-disk format.
As part of this, switch from `atoi()` to `g_ascii_string_to_unsigned()`
for parsing the relevant fields from a GIR XML file. This means we now
get error handling for invalid integers.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
`GIIrNodeType` is built dynamically at runtime (rather than being
mmapped from disk), so its types can accurately reflect their runtime
semantics, rather than an on-disk format.
As part of this, switch from `atoi()` to `g_ascii_string_to_unsigned()`
for parsing the relevant fields from a GIR XML file. This means we now
get error handling for invalid integers.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
We are using various indexes types, but not always using the correct
sign or size, so let's adapt this to ensure we're consistent with the
values we're comparing with.
We just do a safe s/gsize/size_t/ replacement here without doing any
changes to places in which different size of size_t and gsize may be
actually different and create troubles.
Review and update the documentation, making sure it’s complete,
formatted in gi-docgen format, and has all appropriate GIR annotations
and `Since:` lines.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Now that libgirepository uses `GI_AVAILABLE_IN_*` macros, that’s what
controls symbol visibility. The `_` prefixes are redundant, and out of
keeping with the rest of GLib.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Rather than a mix of structs being in `GI` and their methods being in
`g_`.
We’ve chosen not to use the `g_` namespace because a number of the
libgirepository class names are quite generic, so we’d end up with
confusing symbols like `GScopeType` and `GArgument`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
