g-ir-generate crashes on LANGUAGE_INVALID in HarfBuzz-0.0.typelib: write_constant_value: code should not be reached
This is with GObject-Introspection 1.74.0 as packaged in Debian, with Harfbuzz 8.0.0 and previously 6.0.0; also reproduced by someone else, in Gentoo, with an unspecified version of GObject-Introspection and Harfbuzz 6.0.0. See https://github.com/harfbuzz/harfbuzz/issues/4263
HarfBuzz contains this constant:
/**
* HB_LANGUAGE_INVALID:
*
* An unset #hb_language_t.
*
* Since: 0.6.0
*/
#define HB_LANGUAGE_INVALID ((hb_language_t) 0)
During the Debian packaging, we generate GIR stuff in the usual way, the same as upstream: compile C code to a binary, scan the C code and introspect the binary with g-ir-scanner to get GIR XML, compile GIR XML to a typelib with g-ir-compiler, install the GIR XML into our -dev package (similar to Red Hat -devel), and install the typelib into its own package.
g-ir-scanner serializes HB_LANGUAGE_INVALID
into GIR XML like this, which seems an entirely reasonable representation to me, although a GIR expert might notice something wrong?
<constant name="LANGUAGE_INVALID"
value="0"
c:type="HB_LANGUAGE_INVALID"
version="0.6.0">
<doc xml:space="preserve"
filename="src/hb-common.h"
line="327">An unset #hb_language_t.</doc>
<source-position filename="src/hb-common.h" line="334"/>
<type name="language_t" c:type="hb_language_t"/>
</constant>
For unknown reasons, a Debian user wanted to re-generate GIR XML from the typelib we provide, using g-ir-generate, instead of using the GIR XML that we also provide. Apparently this is something that is meant to be possible, although it's a lossy process because the typelib contains less information than the GIR XML. I don't know why the user wanted to do it this way.
Steps to reproduce:
apt install gir1.2-harfbuzz-0.0 libharfbuzz-dev
g-ir-generate /usr/lib/x86_64-linux-gnu/girepository-1.0/HarfBuzz-0.0.typelib > new.gir
and compare the new.gir
generated by g-ir-generate with the /usr/share/gir-1.0/HarfBuzz-0.0.gir
provided by Debian.
Expected result: new.gir
is generated successfully and contains almost the same information as HarfBuzz-0.0.gir
.
Actual result:
<?xml version="1.0"?>
<repository version="1.0"
xmlns="http://www.gtk.org/introspection/core/1.0"
xmlns:c="http://www.gtk.org/introspection/c/1.0"
xmlns:glib="http://www.gtk.org/introspection/glib/1.0">
<include name="freetype2" version="2.0"/>
<include name="GObject" version="2.0"/>
<namespace name="HarfBuzz" version="0.0" shared-library="libharfbuzz-gobject.so.0,libharfbuzz.so.0" c:prefix="hb_">
<constant name="AAT_LAYOUT_NO_SELECTOR_INDEX" value="65535">
<type name="gint32"/>
</constant>
<constant name="BUFFER_REPLACEMENT_CODEPOINT_DEFAULT" value="65533">
<type name="gint32"/>
</constant>
<constant name="CODEPOINT_INVALID" value="4294967295">
<type name="guint32"/>
</constant>
<constant name="FEATURE_GLOBAL_START" value="0">
<type name="gint32"/>
</constant>
<constant name="FONT_NO_VAR_NAMED_INSTANCE" value="-1">
<type name="gint32"/>
</constant>
**
ERROR:../girepository/girwriter.c:784:write_constant_value: code should not be reached
<constant name="LANGUAGE_INVALID" value="Bail out! ERROR:../girepository/girwriter.c:784:write_constant_value: code should not be reached
[1] 111901 IOT instruction (core dumped) g-ir-generate /usr/lib/x86_64-linux-gnu/girepository-1.0/HarfBuzz-0.0.typelib
I assume this must mean one of two things:
- g-ir-compiler wrote out an incorrect typelib in response to the input GIR XML, and g-ir-generator cannot parse it; or
- g-ir-compiler wrote out a correct typelib, but g-ir-generator is parsing it incorrectly.