Re: gdk_pixdata_deserialize byte order problem

[Tim Janik <timj gtk org>]

On Thu, 17 May 2007, Joern P. Meier wrote:

> Hi,
>
> I had some problems with icons from the built-in cache not being loaded
> on Mac/PPC. I traced the problem to gdk_pixdata_deserialize (in
> gdk-pixdata.c) and noticed that the magic word was reversed.
>
> In gdk_pixdata_serialize, g_htonl is used for header fields:
>
>  *istream++ = g_htonl (GDK_PIXBUF_MAGIC_NUMBER);

this is supposed to write out:
	/* Pixbuf magic (0x47646b50) */
	"GdkP"
i.e.:
	stream[0] = 'G'; stream[1] = 'd'; stream[2] = 'k'; stream[3] = 'P';
the above is the "network byte order" and should be generated on little
and big endian machines.

> However, in gdk_pixdata_deserialize, get_uint32 is used:
>
>  stream = get_uint32 (stream, &pixdata->pixdata_type);

right, get_uint32 is supposed to be host endianness agnostic though.

> which seems to store values in network byte order:
>
>  *result = (stream[0] << 24) + (stream[1] << 16) + (stream[2] << 8) +
> stream[3];

nope, read again. the above code does:
  put stream[0] ('G') into the uppermost byte (* 16777216)
  put stream[1] ('d') into the second uppermost byte (* 65536)
  put stream[2] ('k') into the second lowermost byte (* 256)
  put stream[3] ('P') into the uppermost byte (* 1)
that is, you should end up with 0x47646b50, regardless of
the byte order in which the host stores integers.
it's simple host-endianess agnostic arithmetics.

> I was able to fix it by adding a call to g_ntohl in get_uint32.

hm, the question is why you were able to fix things with that.
can you take a look at stream and see whether it possibly stores
"PkdG"? then adding g_ntohl to get_uint32 would reverse matters
and appear to work, but you actually have a bug on the generation
side then.

> Cheers,
>
> Jörn

---
ciaoTJ