4.79 crash on unicode-flagged WindowText/WindowTextWidth

Both of the following Lua lines crash MUSHclient 4.79. If I remove the "true" from the end there's no crash.

The symbol above is the acute accent.

The string you mention is, of course, bad UTF8*. The crash is fixed in version 4.80.

* It is 0xB4 which is not valid on its own inside a UTF8 string. It should be converted to a UTF8 equivalent, namely in this case:



As a work-around, the server should not be sending such a string to UTF8-enabled clients, and if it is generated by a plugin, then it should also not be using such a string.

Of course, but the functions should be returning -3 for bad utf as mentioned in the docs. This affects mapper.lua, by the way. I wonder if all those utf trues should be removed.

There was a bug. It's been fixed.

It was actually caused indirectly because the author of the PCRE library changed the way that the underlying function worked from returning "good" or "bad" to a "how bad" code and an offset. Somehow I didn't implement that correctly when the new library came out.

The UTF "true" are needed to handle the case for if you actually supply UTF8 strings.

Huh. Then I don't understand when the -3 error return code described in the doc for WindowTextWidth would happen.

In the fixed version, your problem line will return -3.

That is, you claim to be supplying UTF8, but you are not.

Right, good. This means though that the room name overlays in mapper.lua do not display correctly if the room name is, for example, "Academy´s Entrance" or "-=]·Sn00bie HQ·[=-" (actual rooms in Aardwolf with acute accent and middle dot respectively, presumably for style reasons) unless all those "true"s are removed. Is Aardwolf sending the wrong thing over GMCP?

Well we had a lengthy discussion about Unicode during the development of GMCP. Since I believe the data is sent in JSON format, consider:

http://www.json.org/fatfree.html



I don't recall what the end specification for GMCP was, but I do recall that a very lengthy and somewhat, er, robust debate occurred on the point of whether or not everything was UTF8.

I would suggest that, based on the above, and since you have Unicode set to "true" in the plugin, you should be assuming that the strings are UTF8. Therefore the server should be encoding any string data as UTF8. In particular, anything above 0x7F would need to be properly encoded, like the quote sign you showed.

I seem to recall that Zugg was very emphatic that the JSON would be Unicode, so one presumes and hopes that CMud would correctly handle the UTF8-encoded data, if the server was changed to send it. However it is interesting that, I guess, you haven't had any complaints from CMud users so far about this particular problem.

See this page for confirmation that the GMCP (ATCP2) data should be UTF8-encoded:

mudstandards.org/forum/viewtopic.php?f=7&t=107

(Keep reading all 9 pages, Unicode gets a mention from time to time).

[EDIT] (April 2015) Warning: Domain name mudstandards.org has been abandoned. That site is now an adult products shop.