thakis added a comment.
Hi,
this causes a warning in harfbuzz on code that looks like so:
UChar decomposed[4];
...
int len = unorm2_getRawDecomposition(...decomposed, ARRAY_LENGTH
(decomposed)...)
if (len == 1) {
U16_GET_UNSAFE (decomposed, 0, *a);
where `U16_GET_UNSAFE` looks like so:
#define U16_GET_UNSAFE(s, i, c) UPRV_BLOCK_MACRO_BEGIN { \
(c)=(s)[i]; \
if(U16_IS_SURROGATE(c)) { \
if(U16_IS_SURROGATE_LEAD(c)) { \
(c)=U16_GET_SUPPLEMENTARY((c), (s)[(i)+1]); \
} else { \
(c)=U16_GET_SUPPLEMENTARY((s)[(i)-1], (c)); \
} \
} \
} UPRV_BLOCK_MACRO_END
(The BLOCK_MACRO macros are just a way to spell `do...while(false)` as far as I
understand.)
It's true that the else block in the macro evaluates to decomposed[0-1], which
is out of bounds -- but it's also in a conditional, and in a macro. That seems
like this can cause quite a few false positives. Maybe this warning should be
suppressed in conditionals, or macros, or some such?
(50k/70k files of chromium built with this patch, this so far is the only
instance it flagged, and that's a false positive.)
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D71714/new/
https://reviews.llvm.org/D71714
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
