Service_International,7 considered harmful

I discovered this last year and forgot to document it.

Service_International,7 – define a VDU glyph by Unicode – is broken; has always been broken; has never worked correctly; cannot be relied upon; must be deprecated.

There is a bug in the International module, which provides many Unicode characters. It contains a number of ranges of character definitions. If one requests a Unicode outside those ranges it passes the service on to other modules as it should. Unfortunately, some of those ranges are sparse, and if you happen to request a Unicode which is within a range but not actually present, International corrupts R4 (the Unicode) before passing on the service.

So, if International doesn’t have it, no one else can have it either.

Fixing this is utterly pointless. This API has never worked. Providers of additional characters (me) cannot use &43,7 because the likelihood of code running on a system where International has been fixed is unlikely or unpredictable. In the absence of a fix, some work-around is required. And if you’re using a work-around for an API that has never worked, why use the original API at all?

For prototyping I have adopted reason code &70000 (Unilaterally. Sue me. I’m using the next 255 as well for other things) which has the same API. If that fails, then I fall back to &43,7 for the International module ONLY.

I would advise anyone writing Unicode character supplying modules to respond to both reason codes identically (once they’ve been finalised – I should get some allocated really).