Re: NSBitmap+Icns.m on Sparc

[David Ayers]

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