================
@@ -484,6 +484,26 @@ bool
clang::analyze_format_string::parseFormatStringHasFormattingSpecifiers(
return false;
}
+ArgType clang::analyze_format_string::wToArgType(
+ int size, bool fast, ASTContext &C) {
+ ArgType fastType = C.getTargetInfo().getTriple().isArch64Bit() ?
C.LongLongTy : C.IntTy;
----------------
jyknight wrote:
It's actually quite a mess right now...
We currently have TargetInfo getIntTypeByWidth/getLeastIntTypeByWidth, but, no
getFastIntTypeByWidth.
And this is a real problem...e.g. clang's stdint.h builtin-header goes through
a ton of complexity to obfuscate that in fact it just ends up defining
int_leastN_t and int_fastN_t as aliases to intN_t, on all platforms we support
(which have all of 8/16/32/64-bit types available.)
But, clang's stdint.h defers to the libc's stdint.h if that exists, and e.g. on
glibc, int_fast{16|32}_t are instead defined as int (32bit) or long (64bit).
OK, fine...Except -- we ALSO define a bunch of preprocessor macros for the fast
types in InitPreprocessor (e.g. `__INT_FAST16_TYPE__`. Which assume that fast
== least. And, of course, these don't match the libc stdint.h's definitions...
And then there's the problem of which of 'long' vs 'long long' is used on
various platforms, when both are 64-bit types.
I think we need to fix all that as a prerequisite. At that point, this code
simply calls getFastIntTypeByWidth.
https://github.com/llvm/llvm-project/pull/71771
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
