# HG changeset patch
# User Luke Schierer <lschiere@pidgin.im>
# Date 1053263557 0
# Node ID 49f857d4b75430dc520b42e944379d58681c24ab
# Parent  908f3d9ee660f6c6e50b86b536226385f10302b7
[gaim-migrate @ 5811]
Tim Mooney (enchanter) writes:
"In src/protocols/jabber/jabber.c, in the function
`jabber_xfer_read',
sscanf is called like such:

sscanf(lenstr, "Content-Length: %d", &size);

The problem is that `size' is of type `size_t', which
is always the largest
integral type size supported on your platform.

That means on 32 bit platforms, it's either a long or
an int (they're the
same, 32 bits wide), and using %d as the format is ok.

On 64 bit platforms, size_t will be a long, so using %d
isn't sufficient.

Since size_t is always as big as a `long' on every
platform, even 32 bit
platforms, there should be no problem switching the
format to %ld.
That will fix the problem for 64 bit platforms, and
shouldn't cause any
change on 32 bit platforms.

Patch is attached. The problem was detected and
warned about by the
vendor compiler on the 64 bit platform I'm using, Tru64
UNIX."

since it still compiles here, i'm putting this in

committer: Tailor Script <tailor@pidgin.im>

diff -r 908f3d9ee660 -r 49f857d4b754 src/protocols/jabber/jabber.c
--- a/src/protocols/jabber/jabber.c	Sun May 18 09:38:55 2003 +0000
+++ b/src/protocols/jabber/jabber.c	Sun May 18 13:12:37 2003 +0000
@@ -2065,7 +2065,7 @@
 			if(data->newline) {
 				gchar *lenstr = strstr(data->headers->str, "Content-Length: ");
 				if(lenstr) {
-					sscanf(lenstr, "Content-Length: %d", &size);
+					sscanf(lenstr, "Content-Length: %ld", &size);
 					gaim_xfer_set_size(xfer, size);
 				}
 				gaim_xfer_set_read_fnc(xfer, NULL);