Hi,

Riccardo Mottola wrote:
Fred Kiefer wrote:
Could you please print out the value of ptr->offset ?
I expect that this is 0 in your case, which would break the calculation
in the inline function decode().
If this is the case we might just add a  zero test to the function or
try to find out why this is the case for you.
If the value isn't zero, we need to take a closer look at that function.
I must admit I don't understand what it actually does :-(
It actually is not 0, look:

-[GSTimeZone initWithName:data:] (self=0x199d90,
    _cmd=0xfe8bd5a0 <_OBJC_SELECTOR_TABLE+224>, name=0x1036e0,
    data=<optimized out>) at NSTimeZone.m:3119
3119              types[i].offset = decode(ptr->offset);
(gdb) p ptr
$1 = (struct ttinfo *) 0x199d46
(gdb) p ptr->offset
$2 = "\000\000\034 "

cheking the loop information:
(gdb) p n_types
$7 = 6
(gdb) p i
$8 = 0

it means it chokes at the first run through.

I peeked at the data:

(gdb) po  name
Europe/Rome
(gdb) po data
<545a6966 00000000 00000000 00000000 00000000 00000006 00000006 00000000 000000a

But honestly, I don't too have a clue about what the function really does and the time zone format. Although

http://en.wikipedia.org/wiki/Tz_database

Proved an interesting lecture :)

I worked on this futher with Fred, we had a doubt about NEED_WORD_ALIGNMENT which was set to 0, but I remember that SPARC is sensitive to memory alignment.

I set it manually to 1 in our config.h, recompiled base and now Ink starts up fine as well as other apps (Although GWorkspace has a couple of problems).

Maybe our test is not working or by Foricing it andusing the memcpy() version other problems are hidden and it is corect that word alignment is not needed.

I hope Richard can shed some light into this when he gets back.

Riccardo

<<attachment: riccardo_mottola.vcf>>

_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Reply via email to