[tex-k] bug in mf.web?

[Don Hosek]

I think you’re misinterpretting what Knuth says about packed_ASCII_code. He’s not allowing for negative values for ASCII codes in the comments, but rather working around the fact that for some Pascal compilers only allow for a signed 8-bit data type.

So ASCII_code must always be in the range 0..255. If the compiler doesn’t have an unsigned 8-bit data type, then the macros si and so must be defined to translate ASCII_code into a packed_ASCII_code. Simply copying an 8-bit unsigned value into an 8-bit signed field does not meet the requirements and would be a bug in the change file. There’s no real advantage to doing something different from 
  si(#) ≡ #-128
  si($) ≡ #+128
your code would run slower and require other changes as you’ve noted.

(and man, it’s been a long time since I dug into this level of Pascal code—I think the last Pascal program I wrote was ca 1991.)

> On 2 Jun 2021, at 11:57, 胡亚捷 (Hu Yajie) <2500418497 at qq.com> wrote:
> 
> I wonder if this is a bug in mf.web: module 37 says that "we access the
> string pool only via" si and so, which convert between ASCII characters
> (0..255) and their internal representations in the string pool (either
> 0..255 or -128..127). However, the function str_vs_str of module 46
> fails to do so and fetches characters from the string pool directly, so
> it compares not the ASCII codes but their internal representations.
> 
> This is harmless if the internal representation is also 0..255, or if
> it is -128..127 by shifting the whole range by 128 (since the relative
> order of characters will be preserved); but if it is -128..127 using
> two's complement, the function may return wrong results.<mfbug.png>