On Wed, 17 Jan 2024 at 16:02, Gabriel Krisman Bertazi <krisman@xxxxxxx> wrote:
>
> No, you are right. In fact, it seems d_compare can't propagate errors
> anyway as it is only compared against 0, anyway.
Note that the whole "malformed utf-8 is an error" is actually wrong anyway.
Yes, if you *output* utf-8, and your output is malformed, then that's
an error that needs fixing.
But honestly, "malformed utf-8" on input is almost always just "oh, it
wasn't utf-8 to begin with, and somebody is still using Latin-1 or
Shift-JIS or whatever".
And then treating that as some kind of hard error is actually really
really wrong and annoying, and may end up meaning that the user cannot
*fix* it, because they can't access the data at all.
And yes, I realize that if somebody is an unicode person, they go "oh,
but it *IS* an error, and you need to detect it".
At that point you should just block that paper-pushing pinhead from your life.
Bad locales happen. It's just a fact of life. The patch that makes an
exact lookup work even when some locale rule is being violated should
be seen as an absolute win, not as a failure to detect an error.
This is another case of the old adage: be conservative in what you do,
be liberal in what you accept from others.
I find libraries that just error out on "malformed utf-8" to be
actively harmful.
Linus
