bug#58168: string-lessp glitches and inconsistencies

[Mattias Engdegård]

4 okt. 2022 kl. 18.24 skrev Eli Zaretskii <eliz@gnu.org>:

>> This treats unibyte format strings as if they were Latin-1 for the purpose 
>> of the error message.
> 
> No, it doesn't.  It shows the problematic characters as raw bytes, as
> in "%\200" (where \200 is a single character).  If you see something
> different, please show the recipe.

   (format-message "%\345" 0)
=> (error "Invalid format operation %å")

where the format string is a unibyte string of two bytes, % and 0xFC, yet the 
error treats it as the Latin-1 character å.

In fact,

   (format-message "%å" 0)

yields the same error string.

>> Not very important, of course, but maybe there should be a UNIBYTE_TO_CHAR 
>> in the alternative branch?
> 
> No, that would show the multibyte codepoint, and will confuse users,
> because the result would look very different from the problematic
> format spec in this case.

Yes, that's probably right. I suppose the right solution is something like:

              unsigned char *p = (unsigned char *) format - 1;
              if (multibyte_format)
                error ("Invalid format operation %%%c", STRING_CHAR (p));
              else
                error (*p <= 127 ? "Invalid format operation %%%c"
                                 : "Invalid format operation char 0x%02x",
                       *p);

but perhaps it's a rare error not worth the trouble. (If we don't bother 
changing it, a little comment saying that we are aware of the glitch may be a 
good idea.)

> Who said anything about #x3fffc?  The original code had #xfc, the
> unibyte code for #x3ffffc.

There seems to be a misunderstanding. The original (and current) code attempts 
to display char #x3fffc, which is not a raw byte. It's just a typo for #x3ffffc 
-- not a big deal.

Of course I could have retained the 3fffc under a different label, but everyone 
else reading the test would just assume it was a typo of 3ffffc since 3fffc 
itself is not very interesting. I replaced it with 10abcd, a wide Unicode value 
deliberately chosen to be arbitrary-looking. We could use another value if you 
prefer.

>  I don't see why we shouldn't test both.
> In the other problematic hunk you replaced \777774 with \374 -- why?

3fffc in octal is 777774; when changed to 3ffffc it becomes a raw byte, fc, 
displayed as \374.