On Thursday 15 October 2009, Redirect "Slash" NIL wrote: > > - "%lld" being correct when the parameter is a "long long", > > as it *IS* here, but for some reason this patch changed > > those to require uint64_t and PRIi64. > > > > The issue with MinGW right now is that it does not (want to) support the > "ll" length modifier (which might be a GCC on Windows enforcement issue, > some background of which is highlighted in this thread: > http://article.gmane.org/gmane.comp.gnu.mingw.announce/1363).
Or in short: Microsoft still doesn't obey standards it doesn't control. And MinGW is following their line. Even when told a "--std=..." to use. > Now, I do realize now that I inadvertently used PRI*i*64 instead of PRI*d*64 > in my patch for %lld replacement (which is plain wrong). Is that why the > %lld -> PRI#64 modifications were rejected? I have no problem at all with PRIu64 when used with uint64_t. However, using it with other types doesn't necessarily work. > If so, I'll make sure resubmit with PRId64. > > If not, my understanding (from > http://en.wikipedia.org/wiki/Printf#printf_format_placeholders) that ISO C99 > mandates the use of PRI#64 as a replacement for %ll# in printf statements. Read more carefully. It doesn't say they are always equivalent; it just says they often are. PRIu64 pairs with uint64_t and so on, but uint64_t need not be "long long" ... so using PRIu64 and passing a "long long" is not necessarily going to work. > Therefore I would believe that 'printf("value: %lld\n", val)' is completely > equivalent to 'printf("value: " PRId64 "\n", val)', and should not break > anything on any platform - on the contrary, it should make the code even > more portable. Only when "val" is of type "int64_t". > Or am I misunderstanding something about the use of the PRI#64 modifiers? > > > As to "%zu" and "%jd", those modifiers were also rejected by MinGW-W64 > ("unknown conversion type character in format"), eventhough they're ISO C99. Seems the MinGW compiler should then reject the "--std=..." command line parameter... that's really the root cause here. We're telling it to conform to that standard, and it's refusing. Nothing to do with Microsoft; just with the toolchain falsely claiming conformance. > From looking around, I think there's probably a way to get MinGW to accept > them, which would alleviate the need for a patch. http://www.opengroup.org/onlinepubs/9699919799/basedefs/inttypes.h.html points out that PRIdMAX and similar printf/scanf formats exist. That should help with "%jd" at least, but there weren't many spots where that was the issue. - Dave > I'll get back to the list when I have tried building against the latest > tree. > > Regards, > > >NIL: > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
