annotate pixmaps/oneeye.xpm @ 5431:49f857d4b754

[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 <[e-mail]>

/* XPM */
static char *oneeye_xpm[] = {
"19 19 6 1",
" 	c None",
".	c #000000",
"X	c #FFFF00",
"o	c #0033FF",
"0	c #FF3300",
"+      c #FFFFFF",
"      .......      ",
"    ..XXXXXXX..    ",
"   .XXXXXXXXXXX.   ",
"  .XXXXXXXXXXXXX.  ",
" .XXXXX.....XXXXX. ",
" .XXXX.+++++.XXXX. ",
".XXXX.++ooo++.XXXX.",
".XXXX.++ooo++.XXXX.",
".XXXXX.+++++.XXXXX.",
".XXXXXX.....XXXXXX.",
".XXX.XXXXXXXXX.XXX.",
".XX.XXXXXXXXXXX.XX.",
".X.X.XXXXXXXXX.X.X.",
" .XXX.XXXXXXX.XXX. ",
" .XXXX.......XXXX. ",
"  .XXX.00.00.XXX.  ",
"   .XXX.000.XXX.   ",
"    ..XXXXXXX..    ",
"      ........     "};