bug#58168: string-lessp glitches and inconsistencies

["Mattias Engdegård" <mattias.engdegard@gmail.com>]

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.