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: Fred Kiefer
Subject: Re: Lost information converting decoded value to in32_t
Date: Mon, 25 May 2020 09:50:26 +0200

> Am 25.05.2020 um 09:28 schrieb RIccardo Mottola <address@hidden>:
> 
> I noticed that on a totally fresh installation on intel 32bit, I get many 
> warnings of the type "Lost information converting decoded value to in32_t" 
> when starting GWorkspace.
> 
> Putting a breakpoint, I noticed that this issue is not coming from "my" code 
> but directly from NSUnarchiver of the GSGormLoader.
> 
> Is it a bug? or did some types change and broke compatibility with existing 
> gorm types?
> 
> 
> 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.

Hope this helps,
Fred


reply via email to

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