win32: use PRId64 instead of %lld

Replace %lld occurrences by PRId64.

Incidentally, this fixes use of curl on Windows, and prevents an assert when closing Qemu.

Signed-off-by Herve Poussineau <[email protected]>

---
 block/curl.c           |   10 +++++-----
 block/qcow2.c          |    2 +-
 hw/vga.c               |    2 +-
 json-lexer.c           |   16 ++++++++++++++++
 json-parser.c          |    2 +-
 qemu-img.c             |    8 ++++----
 qemu-io.c              |   24 ++++++++++++------------
 target-ppc/translate.c |    6 +++---
 8 files changed, 43 insertions(+), 27 deletions(-)

block/curl.c +0 -0

index 5223ce8..a9355fb 100644

json-lexer.c +15 -0

index 53697c5..9d64920 100644
@@ -54,6 +54,9 @@ enum json_lexer_state {
     IN_ESCAPE,
     IN_ESCAPE_L,
     IN_ESCAPE_LL,
+    IN_ESCAPE_I,
+    IN_ESCAPE_I6,
+    IN_ESCAPE_I64,
     IN_ESCAPE_DONE,
     IN_WHITESPACE,
     IN_OPERATOR_DONE,

@@ -223,6 +226,18 @@ static const uint8_t json_lexer[][256] =  {
         ['l'] = IN_ESCAPE_LL,
     },
 
+    [IN_ESCAPE_I64] = {
+        ['d'] = IN_ESCAPE_DONE,
+    },
+
+    [IN_ESCAPE_I6] = {
+        ['4'] = IN_ESCAPE_I64,
+    },
+
+    [IN_ESCAPE_I] = {
+        ['6'] = IN_ESCAPE_I6,
+    },
+
     [IN_ESCAPE] = {
         ['d'] = IN_ESCAPE_DONE,
         ['i'] = IN_ESCAPE_DONE,

qemu-img.c +4 -4

index 3cea8ce..8a33a3d 100644
@@ -724,8 +724,8 @@ static int img_convert(int argc, char **argv)
                     bs_offset += bs_sectors;
                     bdrv_get_geometry(bs[bs_i], &bs_sectors);
                     bs_num = 0;
-                    /* printf("changing part: sector_num=%lld, "
-                       "bs_i=%d, bs_offset=%lld, bs_sectors=%lld\n",
+                    /* printf("changing part: sector_num=%" PRId64 ", "
+                       "bs_i=%d, bs_offset=%" PRId64 ", bs_sectors=%" PRId64 "\n",
                        sector_num, bs_i, bs_offset, bs_sectors); */
                 }
                 assert (bs_num < bs_sectors);

@@ -770,8 +770,8 @@ static int img_convert(int argc, char **argv)
                 assert (bs_i < bs_n);
                 bs_offset += bs_sectors;
                 bdrv_get_geometry(bs[bs_i], &bs_sectors);
-                /* printf("changing part: sector_num=%lld, bs_i=%d, "
-                  "bs_offset=%lld, bs_sectors=%lld\n",
+                /* printf("changing part: sector_num=%" PRId64 ", bs_i=%d, "
+                  "bs_offset=%" PRId64 ", bs_sectors=%" PRId64 "\n",
                    sector_num, bs_i, bs_offset, bs_sectors); */
             }
 

qemu-io.c +12 -12

index b159bc9..4aa2ae5 100644
@@ -108,7 +108,7 @@ print_report(const char *op, struct timeval *t, int64_t offset,
 	if (!Cflag) {
 		cvtstr((double)total, s1, sizeof(s1));
 		cvtstr(tdiv((double)total, *t), s2, sizeof(s2));
-		printf("%s %d/%d bytes at offset %lld\n",
+		printf("%s %d/%d bytes at offset %" PRId64 "\n",
 			op, total, count, (long long)offset);
 		printf("%s, %d ops; %s (%s/sec and %.4f ops/sec)\n",
 			s1, cnt, ts, s2, tdiv((double)cnt, *t));

@@ -150,7 +150,7 @@ create_iovec(QEMUIOVector *qiov, char **argv, int nr_iov, int pattern)
 		}
 
 		if (len & 0x1ff) {
-			printf("length argument %lld is not sector aligned\n",
+			printf("length argument %" PRId64 " is not sector aligned\n",
 				len);
 			goto fail;
 		}

@@ -398,7 +398,7 @@ read_f(int argc, char **argv)
 
 	if (!pflag)
 		if (offset & 0x1ff) {
-			printf("offset %lld is not sector aligned\n",
+			printf("offset %" PRId64 " is not sector aligned\n",
 				(long long)offset);
 			return 0;
 

@@ -429,7 +429,7 @@ read_f(int argc, char **argv)
 		void* cmp_buf = malloc(pattern_count);
 		memset(cmp_buf, pattern, pattern_count);
 		if (memcmp(buf + pattern_offset, cmp_buf, pattern_count)) {
-			printf("Pattern verification failed at offset %lld, "
+			printf("Pattern verification failed at offset %" PRId64 ", "
 				"%d bytes\n",
 				(long long) offset + pattern_offset, pattern_count);
 		}

@@ -533,7 +533,7 @@ readv_f(int argc, char **argv)
 	optind++;
 
 	if (offset & 0x1ff) {
-		printf("offset %lld is not sector aligned\n",
+		printf("offset %" PRId64 " is not sector aligned\n",
 			(long long)offset);
 		return 0;
 	}

@@ -554,7 +554,7 @@ readv_f(int argc, char **argv)
 		void* cmp_buf = malloc(qiov.size);
 		memset(cmp_buf, pattern, qiov.size);
 		if (memcmp(buf, cmp_buf, qiov.size)) {
-			printf("Pattern verification failed at offset %lld, "
+			printf("Pattern verification failed at offset %" PRId64 ", "
 				"%zd bytes\n",
 				(long long) offset, qiov.size);
 		}

@@ -669,7 +669,7 @@ write_f(int argc, char **argv)
 
 	if (!pflag) {
 		if (offset & 0x1ff) {
-			printf("offset %lld is not sector aligned\n",
+			printf("offset %" PRId64 " is not sector aligned\n",
 				(long long)offset);
 			return 0;
 		}

@@ -783,7 +783,7 @@ writev_f(int argc, char **argv)
 	optind++;
 
 	if (offset & 0x1ff) {
-		printf("offset %lld is not sector aligned\n",
+		printf("offset %" PRId64 " is not sector aligned\n",
 			(long long)offset);
 		return 0;
 	}

@@ -868,7 +868,7 @@ aio_read_done(void *opaque, int ret)
 
 		memset(cmp_buf, ctx->pattern, ctx->qiov.size);
 		if (memcmp(ctx->buf, cmp_buf, ctx->qiov.size)) {
-			printf("Pattern verification failed at offset %lld, "
+			printf("Pattern verification failed at offset %" PRId64 ", "
 				"%zd bytes\n",
 				(long long) ctx->offset, ctx->qiov.size);
 		}

@@ -969,7 +969,7 @@ aio_read_f(int argc, char **argv)
 	optind++;
 
 	if (ctx->offset & 0x1ff) {
-		printf("offset %lld is not sector aligned\n",
+		printf("offset %" PRId64 " is not sector aligned\n",
 			(long long)ctx->offset);
 		free(ctx);
 		return 0;

@@ -1064,7 +1064,7 @@ aio_write_f(int argc, char **argv)
 	optind++;
 
 	if (ctx->offset & 0x1ff) {
-		printf("offset %lld is not sector aligned\n",
+		printf("offset %" PRId64 " is not sector aligned\n",
 			(long long)ctx->offset);
 		free(ctx);
 		return 0;

@@ -1214,7 +1214,7 @@ alloc_f(int argc, char **argv)
 
 	offset = cvtnum(argv[1]);
 	if (offset & 0x1ff) {
-		printf("offset %lld is not sector aligned\n",
+		printf("offset %" PRId64 " is not sector aligned\n",
 			(long long)offset);
 		return 0;
 	}

target-ppc/translate.c +3 -3

index d4e81ce..b61c949 100644
@@ -8920,7 +8920,7 @@ void cpu_dump_statistics (CPUState *env, FILE*f,
                         if (handler->count == 0)
                             continue;
                         cpu_fprintf(f, "%02x %02x %02x (%02x %04d) %16s: "
-                                    "%016llx %lld\n",
+                                    "%016" PRIx64 " %" PRId64 "\n",
                                     op1, op2, op3, op1, (op3 << 5) | op2,
                                     handler->oname,
                                     handler->count, handler->count);

@@ -8929,7 +8929,7 @@ void cpu_dump_statistics (CPUState *env, FILE*f,
                     if (handler->count == 0)
                         continue;
                     cpu_fprintf(f, "%02x %02x    (%02x %04d) %16s: "
-                                "%016llx %lld\n",
+                                "%016" PRIx64 " %" PRId64 "\n",
                                 op1, op2, op1, op2, handler->oname,
                                 handler->count, handler->count);
                 }

@@ -8937,7 +8937,7 @@ void cpu_dump_statistics (CPUState *env, FILE*f,
         } else {
             if (handler->count == 0)
                 continue;
-            cpu_fprintf(f, "%02x       (%02x     ) %16s: %016llx %lld\n",
+            cpu_fprintf(f, "%02x       (%02x     ) %16s: %016" PRIx64 " %" PRId64 "\n",
                         op1, op1, handler->oname,
                         handler->count, handler->count);
         }

Signature · 1 line

1.6.0.2.GIT

Quoted 35 lines · Herve Poussineau

Replace %lld occurrences by PRId64.

json-lexer.c +15 -0

index 53697c5..9d64920 100644
@@ -54,6 +54,9 @@ enum json_lexer_state {
     IN_ESCAPE,
     IN_ESCAPE_L,
     IN_ESCAPE_LL,
+    IN_ESCAPE_I,
+    IN_ESCAPE_I6,
+    IN_ESCAPE_I64,
     IN_ESCAPE_DONE,
     IN_WHITESPACE,
     IN_OPERATOR_DONE,

@@ -223,6 +226,18 @@ static const uint8_t json_lexer[][256] =  {
         ['l'] = IN_ESCAPE_LL,
     },
 
+    [IN_ESCAPE_I64] = {
+        ['d'] = IN_ESCAPE_DONE,
+    },
+
+    [IN_ESCAPE_I6] = {
+        ['4'] = IN_ESCAPE_I64,
+    },
+
+    [IN_ESCAPE_I] = {
+        ['6'] = IN_ESCAPE_I6,
+    },
+
     [IN_ESCAPE] = {
         ['d'] = IN_ESCAPE_DONE,
         ['i'] = IN_ESCAPE_DONE,

json-lexer.c static const uint8_t json_lexer[][256] = { · line 251

Quoted 7 lines

json-lexer.c +1 -0

@@ -230,6 +245,7 @@ static const uint8_t json_lexer[][256] =  {
         ['s'] = IN_ESCAPE_DONE,
         ['f'] = IN_ESCAPE_DONE,
         ['l'] = IN_ESCAPE_L,
+        ['I'] = IN_ESCAPE_I,
     },
 
     /* top level rule */

Why do we want yet another tag?

OTOH, Luiz, maybe it is a mistake to use "long"
in QMP: legal values might vary between platforms.
How about we get rid of long and only use long long to mean 64 bit/int to mean 32 bit? Or even redefine "l" to mean 64 bit and "i" to mean "32 bit.

Also, why do we allow "d" as synonym of "i"? Keeping all
of int/long/long long around does not make sense to me though. Finally, don't we want unsigned values in protocol?

On Mon, 25 Jan 2010 12:09:06 +0200
"Michael S. Tsirkin" <[email protected]> wrote:

Quoted 2 lines

Finally,
don't we want unsigned values in protocol?

JSON doesn't support them.

Quoted 2 lines · Luiz Capitulino

On Mon, 25 Jan 2010 12:09:06 +0200
"Michael S. Tsirkin" <[email protected]> wrote:

[...]

Quoted 4 lines

Quoted 2 lines

Finally,
don't we want unsigned values in protocol?

JSON doesn't support them.

Uh, where does the RFC say that?

Quoted 11 lines · On Mon, 25 Jan 2010 15:35:53 +0100 Markus Armbruster <[email protected]> wrote:

Quoted 2 lines · Luiz Capitulino

On Mon, 25 Jan 2010 12:09:06 +0200
"Michael S. Tsirkin" <[email protected]> wrote:

[...]

Quoted 4 lines

Quoted 2 lines

Finally,
don't we want unsigned values in protocol?

JSON doesn't support them.

Uh, where does the RFC say that?

I see that my comment was misleading.

In JSON we don't have unsigned types, we have only a type
called 'number' to represent them all.

Unsigneds should be handled correctly, except for uint64_t which
is cast to int64_t.

Michael, does this answer your question?
Is there any
issue with the handling of unsigneds I'm not aware about?

Quoted 20 lines · Luiz Capitulino

Quoted 11 lines · On Mon, 25 Jan 2010 15:35:53 +0100 Markus Armbruster <[email protected]> wrote:

Quoted 2 lines · Luiz Capitulino

On Mon, 25 Jan 2010 12:09:06 +0200
"Michael S. Tsirkin" <[email protected]> wrote:

[...]

Quoted 4 lines

Quoted 2 lines

Finally,
don't we want unsigned values in protocol?

JSON doesn't support them.

Uh, where does the RFC say that?

I see that my comment was misleading.

In JSON we don't have unsigned types, we have only a type
called 'number' to represent them all.

Quoted 6 lines

Unsigneds should be handled correctly, except for uint64_t which
is cast to int64_t.

Michael, does this answer your question?
Is there any
issue with the handling of unsigneds I'm not aware about?

The issue I see isn't related to unsigned. Apparently we currently accept values such as 'a' as valid strings. Since this is not valid json we probably should reject it just in case we will want to switch to another json library, otherwise clients might come to depend on non-standard behaviour.

On Mon, 25 Jan 2010 17:38:38 +0200
"Michael S. Tsirkin" <[email protected]> wrote:

Quoted 5 lines

The issue I see isn't related to unsigned. Apparently we currently accept values such as 'a' as valid strings. Since this is not valid json we probably should reject it just in case we will want to switch to another json library, otherwise clients might come to depend on non-standard behaviour.

This extension is only used internally by QEMU

and we find it
very convenient otherwise we would have to escape strings in dicts and lists, which is error prone and time consuming.

Quoted 2 lines

This extension is only used internally by QEMU

Let me elaborate: when a QEMP client sends us 'a' over the wire, the parser rejects that as an error. At least that's what we've been promised when the extension was discussed.

Quoted 6 lines · Markus Armbruster

Quoted 2 lines

This extension is only used internally by QEMU

Let me elaborate: when a QEMP client sends us 'a' over the wire, the parser rejects that as an error. At least that's what we've been promised when the extension was discussed.

No, that's never been the case. I don't see the point. JSON allows it. If a client comes to depend on it, so what?

Regards,

Anthony Liguori

Then we'll have to support it forever. Asking clients to only depend on valid JSON will make sure we can use json library in the future, as well as allow easier debugging etc.

Quoted 4 lines · Michael S. Tsirkin

Then we'll have to support it forever. Asking clients to only depend on valid JSON will make sure we can use json library in the future, as well as allow easier debugging etc.

As I mentioned in IRC, I'm not opposed to making this feature of the parser not exposed when dealing with external clients.

But I do believe that we're going to have to extend JSON down the road. This particular extension is unimportant so I don't mind limiting it's visibility.

Regards,

Anthony Liguori

Quoted 6 lines

The issue I see isn't related to unsigned. Apparently we currently accept values such as 'a' as valid strings. Since this is not valid json we probably should reject it just in case we will want to switch to another json library, otherwise clients might come to depend on non-standard behaviour.

This extension is only used internally by QEMU and we find it
very convenient otherwise we would have to escape strings in dicts and lists, which is error prone and time consuming.

Quoted 10 lines · Luiz Capitulino

Quoted 6 lines

The issue I see isn't related to unsigned. Apparently we currently accept values such as 'a' as valid strings. Since this is not valid json we probably should reject it just in case we will want to switch to another json library, otherwise clients might come to depend on non-standard behaviour.

This extension is only used internally by QEMU and we find it
very convenient otherwise we would have to escape strings in dicts and lists, which is error prone and time consuming.

Actually, I was reading the JSON RFC last night and came across:

"A JSON parser transforms a JSON text into another representation. A
JSON parser MUST accept all texts that conform to the JSON grammar. A JSON parser MAY accept non-JSON forms or extensions."

So we are fully JSON compliant in our current implementation.

Regards,

Anthony Liguori

Yes, I agree we are comnpliant.
But I also think we should be strict and reject non-JSON input just so that clients do not come to depend on it.

Quoted 4 lines · Michael S. Tsirkin

Yes, I agree we are comnpliant.
But I also think we should be strict and reject non-JSON input just so that clients do not come to depend on it.

If we can make JSON better while preserving compatibility and adhering to the spec, why wouldn't we?

For instance, at some point in time, we're going to do have to do something about floating point representation.

We have the ability to negotiate these capabilities at run-time.

Regards,

Anthony Liguori

Quoted 3 lines

For instance, at some point in time, we're going to do have to do something about floating point representation.

What's the issue? There's '.' and there's 'e' ...
And maybe we won't need floating point ever ...

Quoted 4 lines · Michael S. Tsirkin

Yes, I agree we are comnpliant.
But I also think we should be strict and reject non-JSON input just so that clients do not come to depend on it.

If we can make JSON better while preserving compatibility and adhering to the spec, why wouldn't we?

For instance, at some point in time, we're going to do have to do something about floating point representation. We have the ability to negotiate these capabilities at run-time.

Quoted 7 lines · Anthony Liguori

Quoted 5 lines · Michael S. Tsirkin

Yes, I agree we are comnpliant.
But I also think we should be strict and reject non-JSON input just so that clients do not come to depend on it.

Quoted 7 lines

If we can make JSON better while preserving compatibility and adhering to the spec, why wouldn't we?

For instance, at some point in time, we're going to do have to do something about floating point representation. We have the ability to negotiate these capabilities at run-time.

Even if we can negotiate extensions at the protocol level, we need to be careful about how we actually use them. The client is likely going to be using whatever standard JSON client comes with their language/environment and will not neccessarily have ability to change that to make use of the QEMU specific extension. We don't want to end up with QEMU having a nice JSON extension for some core feature, but none of the clients being able to use it in practice.

Quoted 8 lines · Luiz Capitulino

Quoted 5 lines

The issue I see isn't related to unsigned. Apparently we currently accept values such as 'a' as valid strings. Since this is not valid json we probably should reject it just in case we will want to switch to another json library, otherwise clients might come to depend on non-standard behaviour.

This extension is only used internally by QEMU and we find it
very convenient otherwise we would have to escape strings in dicts and lists, which is error prone and time consuming.

Actually, I was reading the JSON RFC last night and came across:

"A JSON parser transforms a JSON text into another representation. A
JSON parser MUST accept all texts that conform to the JSON grammar. A JSON parser MAY accept non-JSON forms or extensions."

So we are fully JSON compliant in our current implementation.

The risk is that if we support a private extension (like '') and then json is officially extended to support a conflicting or similar syntax with a different meaning, then we cannot advance to the next revision of json without breaking compatibility.

Quoted 1 line · Avi Kivity

The risk is that if we support a private extension (like '') and then json is officially extended to support a conflicting or similar syntax with a different meaning, then we cannot advance to the next revision of json without breaking compatibility.

The paragraph I quoted from the RFC seems to suggest that the authors of JSON boxed themselves in with respect to extending JSON. The reason being that a conforming implementation is given free reign to extend with "non-JSON forms or extensions". That would seem to prevent any extension.

Keep in mind, JSON is a proper subset of ECMAScript which means the likelihood of extension going outside of ECMAScript would be extremely unlikely. I don't expect JSON is ever going to change.

Quoted 4 lines · Anthony Liguori

Quoted 1 line · Avi Kivity

The risk is that if we support a private extension (like '') and then json is officially extended to support a conflicting or similar syntax with a different meaning, then we cannot advance to the next revision of json without breaking compatibility.

The paragraph I quoted from the RFC seems to suggest that the authors of JSON boxed themselves in with respect to extending JSON. The reason being that a conforming implementation is given free reign to extend with "non-JSON forms or extensions". That would seem to prevent any extension.

A json generator is required to generate conforming text. So there are three choices:

- reject 's
- unofficially accept 's, nonconforming generators break if json changes, nor our problem
- officially accept 's, look stupid when json changes

Quoted 1 line

Quoted 1 line

Keep in mind, JSON is a proper subset of ECMAScript which means the likelihood of extension going outside of ECMAScript would be extremely unlikely. I don't expect JSON is ever going to change.

Who knows? Let's not take unnecessary risks.

Quoted 1 line · Herve Poussineau

Replace %lld occurrences by PRId64.

This is wrong.
long long values should be printed with %lld.
size_t - with %zd. PRId64 is for int64_t.

Quoted 7 lines · Michael S. Tsirkin

Quoted 1 line · Herve Poussineau

Replace %lld occurrences by PRId64.

This is wrong.
long long values should be printed with %lld.
size_t - with %zd. PRId64 is for int64_t.

size_t => %zu, ssize_t => %zd might be better.

And none of them works on win32, so using them
there can result in a crash:

    size_t st = 4711;
    fprintf(stderr, "st=%zu, %s\n", st, "test");

printf functions on win32 don't know %z.
They run

    fprintf(stderr, "st=zu, %s\n", st, "test");

which results in an memory access fault when printf wants to read the memory at address 0x4711.

Regards,
Stefan Weil

Quoted 20 lines · Stefan Weil

Quoted 6 lines · Michael S. Tsirkin

Quoted 1 line · Herve Poussineau

Replace %lld occurrences by PRId64.

This is wrong.
long long values should be printed with %lld.
size_t - with %zd. PRId64 is for int64_t.

size_t => %zu, ssize_t => %zd might be better.

And none of them works on win32, so using them
there can result in a crash:

size_t st = 4711;
fprintf(stderr, "st=%zu, %s\n", st, "test");

printf functions on win32 don't know %z.
They run

fprintf(stderr, "st=zu, %s\n", st, "test");

Quoted 5 lines

which results in an memory access fault when printf wants to read the memory at address 0x4711.

Regards,
Stefan Weil

Let's just implement a compliant printf?

Quoted 21 lines · Michael S. Tsirkin

Quoted 20 lines · Stefan Weil

Quoted 6 lines · Michael S. Tsirkin

Quoted 1 line · Herve Poussineau

Replace %lld occurrences by PRId64.

This is wrong.
long long values should be printed with %lld.
size_t - with %zd. PRId64 is for int64_t.

size_t => %zu, ssize_t => %zd might be better.

And none of them works on win32, so using them
there can result in a crash:

size_t st = 4711;
fprintf(stderr, "st=%zu, %s\n", st, "test");

printf functions on win32 don't know %z.
They run

fprintf(stderr, "st=zu, %s\n", st, "test");

Quoted 7 lines

Quoted 5 lines

which results in an memory access fault when printf wants to read the memory at address 0x4711.

Regards,
Stefan Weil

Let's just implement a compliant printf?

Or format the harddisk and install linux?
Maybe that would be the better option :-)

Of course you can add a printf to qemu, or to mingw32. No need to implement it - there are lots of good free implementations.

The mingw developers are aware of the problem
(http://www.mail-archive.com/[email protected]/msg00416.html).

If there is an easy solution, they will fix the problem.

I don't think the problem can be fixed easy:
there is not only printf but a lot of functions which use format strings. They are implemented in msvcrt.dll. Replacing single functions in a dll is difficult. Telling code which printf in which dll is the correct one is difficult, too.

There are easy solutions for QEMU: type cast size_t values to unsigned or uint32_t in printf or use a new macro (for example PRIsize) in format strings. That macro would be different for mingw32 and standard conforming systems.

Quoted 49 lines · Stefan Weil

Quoted 21 lines · Michael S. Tsirkin

Quoted 20 lines · Stefan Weil

Quoted 6 lines · Michael S. Tsirkin

Quoted 1 line · Herve Poussineau

Replace %lld occurrences by PRId64.

This is wrong.
long long values should be printed with %lld.
size_t - with %zd. PRId64 is for int64_t.

size_t => %zu, ssize_t => %zd might be better.

And none of them works on win32, so using them
there can result in a crash:

size_t st = 4711;
fprintf(stderr, "st=%zu, %s\n", st, "test");

printf functions on win32 don't know %z.
They run

fprintf(stderr, "st=zu, %s\n", st, "test");

Quoted 7 lines

Quoted 5 lines

which results in an memory access fault when printf wants to read the memory at address 0x4711.

Regards,
Stefan Weil

Let's just implement a compliant printf?

Or format the harddisk and install linux?
Maybe that would be the better option :-)

Of course you can add a printf to qemu, or to mingw32. No need to implement it - there are lots of good free implementations.

The mingw developers are aware of the problem
(http://www.mail-archive.com/[email protected]/msg00416.html).

If there is an easy solution, they will fix the problem.

I don't think the problem can be fixed easy:
there is not only printf but a lot of functions which use format strings. They are implemented in msvcrt.dll. Replacing single functions in a dll is difficult. Telling code which printf in which dll is the correct one is difficult, too.

Quoted 5 lines

There are easy solutions for QEMU: type cast size_t values to unsigned or uint32_t in printf or use a new macro (for example PRIsize) in format strings. That macro would be different for mingw32 and standard conforming systems.

The link above suggests adding
-D__USE_MINGW_ANSI_STDIO=1
why don't we do just do this with mingw?

People should also build with -Werror, then
it would be a build error not a crash.

Signature · 1 line

MST

Quoted 22 lines · Stefan Weil

Quoted 7 lines · Michael S. Tsirkin

Quoted 1 line · Herve Poussineau

Replace %lld occurrences by PRId64.

This is wrong.
long long values should be printed with %lld.
size_t - with %zd. PRId64 is for int64_t.

size_t => %zu, ssize_t => %zd might be better.

And none of them works on win32, so using them
there can result in a crash:

    size_t st = 4711;
    fprintf(stderr, "st=%zu, %s\n", st, "test");

printf functions on win32 don't know %z.
They run

    fprintf(stderr, "st=zu, %s\n", st, "test");

Quoted 5 lines

which results in an memory access fault when printf wants to read the memory at address 0x4711.

Regards,
Stefan Weil

Let's just implement a compliant printf?

Quoted 6 lines · Michael S. Tsirkin

Quoted 1 line · Herve Poussineau

Replace %lld occurrences by PRId64.

This is wrong.
long long values should be printed with %lld.
size_t - with %zd. PRId64 is for int64_t.

size_t => %zu, ssize_t => %zd might be better.

And none of them works on win32, so using them
there can result in a crash:

size_t st = 4711;
fprintf(stderr, "st=%zu, %s\n", st, "test");

printf functions on win32 don't know %z.
They run

fprintf(stderr, "st=zu, %s\n", st, "test");

which results in an memory access fault when printf wants to read the memory at address 0x4711.

Regards,
Stefan Weil

Replace %lld occurrences by PRId64.
Incidentally, this fixes use of curl on Windows, and prevents an assert when closing Qemu.