+# There is no ANYOFRr because khw doesn't think there are likely to be
+# real-world cases where such a large range is used.
+#
+# And khw doesn't believe an ANYOFRs (which would behave like ANYOFHs) is
+# actually worth it. On two-byte UTF-8, the first byte alone is all we need,
+# and ANYOFR already does that. And we don't consider non-Unicode code points
+# or EBCDIC for performance decisions. If we had it, we would be comparing the
+# strings, and if they are equal convert to UV and then test to see if it is in
+# the range. The fast DFA we now use to do the conversion is slower than
+# comparing the strings, but not by much, and negligible in 2 or 3 byte
+# operations. (We don't have to compare the final byte as it has to be
+# different or else this wouldn't be a range.) So we might as well displense
+# with the comparisons that ANYOFRs would do, and go directly to do the
+# conversion .
+
+ANYOFHbbm ANYOFHbbm none bbm S ; Like ANYOFHb, but only for 2-byte UTF-8 characters; uses a bitmap to match the continuation byte