gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Lost information converting decoded value to in32_t


From: Riccardo Mottola
Subject: Re: Lost information converting decoded value to in32_t
Date: Mon, 25 May 2020 20:38:27 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

Hi,

On 25/05/2020 09:50, Fred Kiefer wrote:
The first "halt" I get is when loading Attributes.gorm of GWorkspace's Inspector
Looks like your archive has a value that gets encodes as an NSInteger and this is 32 bit on your current machine but the original encoded value was actually 64 bit and uses more than the 32 bit you are able to read. The best thing to do is to find out which value it is that causes the behaviour and encode (and decode) it as a long.

And to answer your question, the message itself is surely not a bug, it just shows how clever base tries to deal with different encoded values. The actual encoding may be a bug. There it would really help to know where it is coming from.


Yes, I understand the error is not in the Unarchiver - I have seen the check.

But my question is why should I have an invalid number in a Gorm file. So either a bug in it, in some archiver or in some compatibility.

From the stacktrace I couldn't undestand what exactly that value is.

I hope it is not an issue of creating a gorm file on a 64bit machine and reading it back on a 32bit or something like that!

First thing, I will see if I can reproduce this on other machines. I do not see this on my workstation, but it is running on 64bit, with a different OS and with a different compiler and runtime :-P Too many differences.


Riccardo


reply via email to

[Prev in Thread] Current Thread [Next in Thread]