[luatex] luaharfbuzz breaks tostring

Simon Dales simon at getthingsfixed.co.uk
Tue Mar 10 08:23:12 CET 2020

Luigi Scarso,

When building/testing the new TeX Live 2020 (for Raspberry Pi) I spotted
an apparent fault with luaharfbuzz.

I did a recursive listing of _G and it broke. Turned out that some of
the classes' tostrings are broken.

The lua reference says that tostring() should return a sensible string
for __all__ values.

for k,v in pairs(luaharfbuzz) do

The errant entries: Direction, Feature, Language, Script, Tag

// investigation
I checked the classes' metatables for __tostring, and the errant ones
all had an entry, and those without worked fine.

Checked the c sources and the classes with a simple register_class()
worked fine. Those that set their own explicit __tostring() caused the

// test 1
In my lua test script I iterated over luaharfbuzz looking for
metatable.__tostring nd set to nil. Then re-listed, and all happy.

// test 2
I checked the sources, commented out their __tostring entries and
rebuilt. The TeX Live ./Build self-tests work OK.

So now the luaharfbuzz table has no __tostrings and now passes.

Now they all return strings of the form: "harfbuzz.wibble: 0x12eac68",
like one would expect.


* How did this get through?
* Is it safe to run luaharfbuzz with their __tostrings suppressed?
* Other/better solution?



More information about the luatex mailing list.