bug#58168: string-lessp glitches and inconsistencies

[Eli Zaretskii <eliz@gnu.org>]

> From: Mattias Engdegård <mattias.engdegard@gmail.com>
> Date: Thu, 6 Oct 2022 14:43:09 +0200
> Cc: larsi@gnus.org,
>  58168@debbugs.gnu.org
> 
> 6 okt. 2022 kl. 13.13 skrev Eli Zaretskii <eliz@gnu.org>:
> 
> >>   (format-message "%\345" 0)
> >> => (error "Invalid format operation %å")
> > 
> > And you want to show %\345 instead?
> 
> Maybe, or (as the patch suggested) using a different wording for raw bytes. In any case %å is clearly a lie since that character wasn't in the format string. What would you rather see in such a case?

I don't think it matters much, because whatever we produce we cannot
be sure it will look identical to the original format string.

> Oh, I see -- you are looking at the hunk that changed the labels, not the character tested. When 3fffc was changed into 3ffffc, the "expected" string needed to change accordingly; for the latter, it's \xfc or \374 depending on mode.
> 
> > Why not test both #x3ffffc and #xfc?  And the same question about
> > \777777 vs \374.
> 
> Testing #x3ffffc inserts the raw byte #xfc so that takes care of that -- the test already exercised inserting the unibyte raw byte #x80 and the patch didn't change that.

We are talking about a test suite.  A test suite doesn't have to
assume that the internals work as they should, it should just test
that.  So testing both sounds to me better than testing just one
assuming that this one covers both.

> I don't think these two cases actually exercise different paths in redisplay since the buffer is multibyte:

Again, this kind of considerations don't have a place in a test
suite.  What if tomorrow redisplay code will change to have two
different paths?

> \777774 is just octal for #x3fffc which was changed into the (intended) #x3ffffc, and \374 is octal for #xfc which is covered as above.

Normally, yes.  But this is a test suite...