[luatex] luaharfbuzz breaks tostring

[luigi scarso]

On Tue, Mar 10, 2020 at 1:24 PM Simon Dales <simon at getthingsfixed.co.uk>
wrote:

> 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
>   print(k,v)
> end
> ////////////////
>
> 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
> problems.
>
> // 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?
>
> /////////////////
>
> Simon
>
>
>
>
>
Thank you very much  for the report;  yes it seems something wrong in the
code.
I will see it asap.


-- 
luigi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/luatex/attachments/20200310/4f74ee07/attachment.html>