Re: Lost information converting decoded value to in32_t

[Richard Frith-Macdonald]

> On 25 May 2020, at 19:38, Riccardo Mottola <address@hidden> wrote:
> 
> 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.

My best guess would be either something like NSNotFound (0xffffffff on 32bit 
0xffffffffffffffff on 64bit) being encoded, or a negative integer accidentally 
being encoded as unsigned.

Apart from that it's hard to find integer values which would break the 32bit 
boundary.