|
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,
The first "halt" I get is when loading Attributes.gorm of GWorkspace's InspectorLooks 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
[Prev in Thread] | Current Thread | [Next in Thread] |