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

[Ruben Van Boxem]

2012/8/9 Jordan Rose <jordan_rose at apple.com>

>
> 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
>

I admit defeat, C is just not my thing, and printf much less so...

http://llvm.org/bugs/show_bug.cgi?id=13565

Ruben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120809/01024fc3/attachment.html>