Re: NSControls failing to set status/label on BigEndian/64bit

[Fred Kiefer]

> Am 06.01.2021 um 22:57 schrieb Wolfgang Lux <wolfgang.lux@gmail.com>:
> 
>> good catch. We have two differences here 32bit vs 64bit, but also signed vs 
>> unsigned!
> 
> the difference between signed and unsigned is irrelevant for encoding and 
> decoding, as you pass a pointer to the memory being encoded or decoded. 
> However, the size of the value you want to encode or decode should agree with 
> the type that is used for coding.

Things are even a bit more complicated here. Richard tries very hard to handle 
different integer and float types in NSUnarchiver. The code tries to match the 
data in the archive to the expected type and that works for many cases. For 
some reason, I am not sure whether this is intentional, it does not map between 
unsigned and signed. So although you are correct that this is not a good idea, 
the code would work with

[aDecoder decodeValueOfObjCType: @encode(NSUInteger)
                                   at: &_highlightsByMask];

It just throws the exception for NSInteger. Still the solution that Riccardo 
calls a dirty hack seems to be the better way to handle the issue.

>> The first thing I tried was to use NSInteger/NSUInteger as approriate in 
>> encodeWithCode and initWithCoder, but Gorm files fail to load
>> "Exception occurred while loading model: expected long long and got unsigned 
>> int"
>> 
>> I then tried just to use int to match NSInteger and reduce the signedness 
>> problem, then I get insted
>> "Exception occurred while loading model: expected int and got unsigned int"
> 
> Yes. Changing the type you pass to the {en,de}codeValueOfObjCType methods is 
> a, errm, not so bright idea. The types are included in the binary archives. 
> So, trying to decode a value with a different type will give you an error 
> (for your own safety and sanity). Trying to encode values with a different 
> type is even worse, as you would be creating archives that cannot be read by 
> anybody else (because they are expecting some other type). If you (have to) 
> make such changes, be sure to introduce a new archive version and be sure to 
> include backward compatibility code for reading the old archive format.

Maybe we should wait before fixing this to hear from Richard what is the 
intended behaviour here. The current code is of course wrong, Providing a 
variable of one type and stating another is bound to fail in some cases. But 
should we rely on the archiver to correct the type or should we use the „dirty 
hack“, which for me is a rather clean solution.
Most likely we have this issue in other places of gui as well. We were just 
lucky that the bits in little endian systems fall into the expected places.

Fred