utf8n_to_uvchr_msgs(): Macroïze a common paradigm

[khwilliamson]

Each of the cases in the loop had a somewhat obscure conditional that had a few variants. This commit creates a macro that puts the complication in one place.

It also fixes a bug found by more robust test cases, yet to be committed. The function can either raise a warning (if appropriate) or pass the needed information about the warning back to the caller when the function parameters say to. The data for each should be identical, but prior to this commit, they weren't in one unlikely case.

This happened when the input UTF-8 sequence represents a code point whose value doesn't fit in the platform's word size. This is viewed as a malformation, and, if enabled, a warning using the WARN_UTF8 category is raised. But if disabled, another way to look at it is that this is an attempt to use a code point that isn't legal Unicode. There is another warnings category for that, WARN_NON_UNICODE. And, so a warning is raised if that category is enabled.

Note that WARN_NON_UNICODE is a subcategory of WARN_UTF8, so the only way to get to this situation is

no warnings 'utf8'; use warnings 'non_unicode';

(those two statements could be separated by many lines)

Prior to this commit, if the caller asked for the warning information to be passed to it instead of raising the warnings, WARN_NON_UNICODE never was returned, making the two modes sometimes inconsistent.

With this commit, WARN_NON_UNICODE is passed to the caller if (and only if) a warning would otherwise have been generated using it.

[mauke]

Wouldn't this be simpler if you invert the order of checks (i.e. check msgs on the inside)?

             : ((ckWARN_d(warning))                                   \
                 ? warning                                            \
                 : ((extra_ckWARN(extra_category)                     \
                    ? extra_category                                  \
                    : (msgs) ? warning : 0))))                        \

[khwilliamson]

Yes, I got fixated on checking msgs first because it is cheaper than the function calls, and lost sight of the fact that that is irrelevant in this case because there is no possible path through the code that doesn't also have a function call

[mauke]

This is not the same logic. In the old version, if msgs was true, ckWARN_d(WARN_UTF8) false, ckWARN_d(WARN_NON_UNICODE) true, we still used WARN_UTF8. With the new macro, we now use WARN_NON_UNICODE.

[khwilliamson]

Yes; it is a bug fix. I don't know why I thought it not necessary to point that out in the commit message. Now revised

[khwilliamson]

I decided that the behavior change should be in a separate pull request, and so I created #22767