[cfe-dev] printf: invalid conversion specifier: 'I' when using "I64d" on Windows

[Jordan Rose]

On Aug 8, 2012, at 2:15 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Wed, Aug 8, 2012 at 2:03 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>> Interesting. Shouldn't be too hard to add support here (conditioned on
>> -fms-compatibility, perhaps?),
> 
> Not -fms-compatibility; the issue is whether the MS runtime is in use,
> which is true in contexts where we don't use -fms-compatibility (like
> MinGW).  There are only a couple relevant target triples, though; we
> can easily check for them.

Ah, I see.

On Aug 8, 2012, at 2:09 PM, Ruben Van Boxem <vanboxem.ruben at gmail.com> wrote:
> If -fms-compatibility is enabled by default on Windows, this is fine by me. But I noticed the glibc and objc stuff is just "in plain sight" too, is this intended or just "easier to implement"?

We should probably guard the glibc extensions better (not just PrintErrno, but some of the non-standard length modifiers). For ObjC, though, the idea is that there is nothing non-standard there -- ObjC format strings should* behave like standard printf format strings except that they have %@ and don't have %n. I suppose this is not guaranteed in all runtimes, but I think we can rely on it.

* ...but this is "should" because of %C, %ls, and %S, which use 'unsigned short' (the 'unichar' typedef) rather than 'wchar_t'. I suppose this is technically a Darwinism.

I would still prefer to have 'I', 'I32', and 'I64' under a guard. If you think there are other modifiers worth guarding, we can do that too. (I'm imagining the case where someone switches platforms a lot, or is a new switcher, and uses the wrong specifier out of habit.)

Jordan