[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSBitmap+Icns.m on Sparc
From: |
David Ayers |
Subject: |
Re: NSBitmap+Icns.m on Sparc |
Date: |
Wed, 05 Nov 2008 17:28:42 +0100 |
Am Mittwoch, den 05.11.2008, 08:45 +0100 schrieb Fred Kiefer:
> Riccardo is having trouble with the new icns loading code on sparc
> architecture. I think this is caused by pointers into the data structure
> not being properly aligned for this processor, but as I am no expert in
> this area it would be great if somebody could have a look before I start
> experimenting around.
>
> The problem he gets is:
> Program received signal SIGBUS, Bus error.
> 0x0fec17e4 in icns_import_family_data (size=33658, bytes=0x9a6e000 "icns",
> iconFamily=0xf7fca660) at NSBitmapImageRep+ICNS.m:270
> 270 while ((data < end) && element->elementSize)
>
>
> (gdb) p data
> $1 = (icns_byte_t *) 0xdce6372 "t8mk"
> (gdb) p end
> $2 = (icns_byte_t *) 0xdcea37a ""
> (gdb) p element->elementSize
> $3 = 16392
Given the definitions of the types:
typedef unsigned char icns_byte_t;
typedef unsigned long icns_size_t;
typedef struct _icns_type_t {
char c[4];
} icns_type_t;
typedef struct _icns_element_t {
icns_type_t elementType;
icns_size_t elementSize;
} icns_element_t;
typedef struct _icns_family_t {
icns_type_t resourceType;
icns_size_t resourceSize;
icns_element_t elements[1];
} icns_family_t;
I would assume the straight forward fix (if indeed it is an alignment
issue is to add padding to icns_element_t to the sizeof(long) boundry
which is 8 byte on most 64 bit archs. I.e.
typedef struct _icns_element_t {
icns_type_t elementType;
char padding[4];
icns_size_t elementSize;
} icns_element_t;
But yeah... maybe we should just look at their code...
Cheers,
David