[libc-commits] [libc] [llvm] [clang-tools-extra] [clang] [flang] Fix clang to recognize new C23 modifiers %w and %wf when printing (PR #71771)

Aaron Ballman via libc-commits libc-commits at lists.llvm.org
Tue Nov 14 10:50:39 PST 2023


================
@@ -286,7 +286,33 @@ clang::analyze_format_string::ParseLengthModifier(FormatSpecifier &FS,
       lmKind = LengthModifier::AsInt3264;
       break;
     case 'w':
-      lmKind = LengthModifier::AsWide; ++I; break;
+      ++I;
+      if (I == E) return false;
+      if (*I == 'f') {
+        lmKind = LengthModifier::AsWideFast;
+        ++I;
+      } else {
+        lmKind = LengthModifier::AsWide;
+      }
+
+      if (I == E) return false;
+      int s = 0;
+      while (unsigned(*I - '0') <= 9) {
+        s = 10 * s + unsigned(*I - '0');
+        ++I;
+      }
+
+      // s == 0 is MSVCRT case, like l but only for c, C, s, S, or Z on windows
+      // s != 0 for b, d, i, o, u, x, or X when a size followed(like 8, 16, 32 or 64)
+      if (s != 0) {
+        std::set<int> supported_list {8, 16, 32, 64};
----------------
AaronBallman wrote:

I think this list is not quite right because we handle some odd sizes as well: https://github.com/llvm/llvm-project/blob/main/clang/lib/Headers/stdint.h#L124

That said, I'm not certain how we would find out which odd sizes are supported; it depends on Clang as well as whatever C standard library is being dispatched to. So I think we should probably err on the side of specifying all the bit-widths we specify in stdint.h.

https://github.com/llvm/llvm-project/pull/71771


More information about the libc-commits mailing list