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.
http://llvm-reviews.chandlerc.com/D1456
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
