Re: [PATCH] Improve error reporting when serializing non-Unicode strings to JSON

[Eli Zaretskii <eliz@gnu.org>]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sat, 23 Dec 2017 15:19:17 +0000
> Cc: phst@google.com, emacs-devel@gnu.org
> 
>  So let's use check_utf_8, as its downsides don't sound serious to me,
> 
> Well it needs to be rewritten significantly to take a char*, length argument instead of the coding_system
> struct.

But creating a coding_system struct requires a single call to
setup_coding_system, which doesn't sound too bad.

> u8-check.c is just 77 LoC (including all boilerplate, comments, and empty lines), so I don't think it blows up
> Emacs in any significant way.

Each unnecessary bloat is significant.  We should always strive to use
the code we already have, because those bloats accumulate.

> Having not much experience with coding.c, I find the functions in that file much more confusing and harder to
> understand than the ones from libunistring. The libunistring functions tend to have a single, clear purpose,
> while the coding.c functions often do many different things at once.

That's exactly what bothers me: the tendency to prefer external code
while leaving the code we have unfamiliar and thus somewhat scary.
I'd prefer that more people will become familiar with coding.c
instead.  (Of course, there's nothing wrong with making its code
cleaner and easier to use, where that's possible.)

> What I need to check is one of the following:
> - Is the initial string either a well-formed UTF-8 unibyte string, or a multibyte string that represents a Unicode
> scalar value sequence?
> - Is the encoded string a well-formed UTF-8 unibyte string?
> Given my understanding of the implementation of coding.c, these two criteria should be equivalent.
> (Unfortunately that doesn't seem to be documented.) So I choose to implement the second check, which is
> easier and allows delaying the check until we know we have to signal an error.

Well, the former should be possible with find_charsets_in_text, but
you rejected that because of the additional performance penalty (which
is something I can understand and sympathize with).