Skip to content

Commit 080baaf

Browse files
committed
handy.h: Fix off-by-1 error in comment
1 parent ee92e19 commit 080baaf

File tree

1 file changed

+9
-9
lines changed

1 file changed

+9
-9
lines changed

handy.h

Lines changed: 9 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -2247,15 +2247,15 @@ END_EXTERN_C
22472247

22482248
#define isBLANK_LC_uni(c) isBLANK_LC_uvchr(UNI_TO_NATIVE(c))
22492249

2250-
/* The "_safe" macros make sure that we don't attempt to read beyond 'e', but
2251-
* they don't otherwise go out of their way to look for malformed UTF-8. If
2252-
* they can return accurate results without knowing if the input is otherwise
2253-
* malformed, they do so. For example isASCII is accurate in spite of any
2254-
* non-length malformations because it looks only at a single byte. Likewise
2255-
* isDIGIT looks just at the first byte for code points 0-255, as all UTF-8
2256-
* variant ones return FALSE. But, if the input has to be well-formed in order
2257-
* for the results to be accurate, the macros will test and if malformed will
2258-
* call a routine to die
2250+
/* The "_safe" macros make sure that we don't attempt to read the byte at 'e'
2251+
* or beyond, but they don't otherwise go out of their way to look for
2252+
* malformed UTF-8. If they can return accurate results without knowing if the
2253+
* input is otherwise malformed, they do so. For example isASCII is accurate
2254+
* in spite of any non-length malformations because it looks only at a single
2255+
* byte. Likewise isDIGIT looks just at the first byte for code points 0-255,
2256+
* as all UTF-8 variant ones return FALSE. But, if the input has to be
2257+
* well-formed in order for the results to be accurate, the macros will test
2258+
* and if malformed will call a routine to die
22592259
*
22602260
* Except for toke.c, the macros do assume that e > p, asserting that on
22612261
* DEBUGGING builds. Much code that calls these depends on this being true,

0 commit comments

Comments
 (0)