[PATCH] Analysis: Add support for MS specific printf format specifiers
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;
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