Re: NSBitmap+Icns.m on Sparc

2008-11-09 Thread Riccardo Mottola 

Hi,

On 2008-11-05 17:28:42 +0100 David Ayers [EMAIL PROTECTED] wrote:


typedef struct _icns_element_t {
  icns_type_t elementType;
  char padding[4];  
  icns_size_t elementSize;
} icns_element_t;


I inserted a padding of 2 and the applicationdidn't carsh anymore, 
meaning that memory is accessed correctly .

Still no image gets displayed and I get an error on the console.

I checked the code and I think all the memcoty code needs to be 
adapted, filling in the structure correctly. I tried to split each 
memcopy in 2... first bytes and latter bytes. Is there a better way? I 
wasn't completely successful, there is a point where the whole header 
gets memcopied.


Riccardo



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

NSBitmap+Icns.m on Sparc

2008-11-05 Thread 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


As it works fine for him when using the libicns library I would not rank
it as a very urgent problem. Still it is interesting to understand how
they are doing it. (OK, we could just have a look at the code, now that
we know it is LGPL)

Fred


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSBitmap+Icns.m on Sparc

2008-11-05 Thread 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




___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev