[PATCH] Analysis: Add support for MS specific printf format specifiers

David Majnemer david.majnemer at gmail.com
Wed Aug 21 13:58:16 PDT 2013

  I've addressed some of these comments inline, I will update the patch with corrections.

Comment at: lib/Analysis/PrintfFormatString.cpp:325-328
@@ -315,2 +324,6 @@
         return ArgType(Ctx.getSizeType(), "size_t");
+      case LengthModifier::AsInt3264:
+        return Ctx.getTargetInfo().getTriple().isArch64Bit()
+                   ? Ctx.UnsignedLongLongTy
+                   : Ctx.UnsignedIntTy;
       case LengthModifier::AsPtrDiff:
Jordan Rose wrote:
> I think just matching AsSizeT here is probably fine, per http://msdn.microsoft.com/en-us/library/tcxf1dw6(v=vs.90).aspx
I is not an analog to POSIX's z/t, it's more like their version of UNIX's variable width long type.

Comment at: lib/Analysis/PrintfFormatString.cpp:313
@@ -306,1 +312,3 @@
+      case LengthModifier::AsInt32:
+        return Ctx.UnsignedIntTy;
       case LengthModifier::AsChar: return Ctx.UnsignedCharTy;
Jordan Rose wrote:
> I don't know if Windows has any ILP64 configurations, but this might need to actually look for "unsigned __int32". At the very least it should use it in the name like "uintmax_t".
> (I'm doing my comments backwards, so all of this applies to the signed integers as well.)
They don't have ILP64 configurations and, in fact, can't for numerous reasons relating to ABI/source compatibility.  __int32 is just a synonym for int that is vended by the compiler.

Comment at: lib/Analysis/FormatString.cpp:544-546
@@ -516,5 +543,5 @@
-  // MacOS X unicode extensions.
+  // POSIX unicode extensions.
   case CArg: return "C";
   case SArg: return "S";
Charles Davis wrote:
> Jordan Rose wrote:
> > Huh, I didn't realize these were present elsewhere. They don't quite behave the same on Windows, right? See http://llvm.org/bugs/show_bug.cgi?id=13565
> Yeah, they don't. In fact, the behavior of these on Windows is very... uh, weird, to say the least. It depends on which function you're calling (`printf` or `wprintf`). There's a handy table above.
> This is so, if you include `<tchar.h>` and call `_tprintf`, you can pass `_TCHAR` strings and it will behave correctly. (The macros and types in `<tchar.h>` behave differently depending on whether or not `_UNICODE` is `#define`d. Same for `<windows.h>` and `UNICODE`.) Note the non-standard `"%hs"` and `"%hc"` formats. They're needed because, in this scheme, there's otherwise no way to always pass a plain ol' `char` string!
They are present elsewhere, all POSIX platforms must have a 'C' and 'S' implementation that desugars to 'lc' and 'ls'

See http://pubs.opengroup.org/onlinepubs/009695399/functions/printf.html for more details.


More information about the cfe-commits mailing list