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

[Richard Frith-Macdonald]

> On 7 Jan 2021, at 17:12, Wolfgang Lux <wolfgang.lux@gmail.com> wrote:
> 
> Am 07.01.2021 um 14:33 schrieb Riccardo Mottola <riccardo.mottola@libero.it>:
>> 
>> Hi all,
>> 
>> 
>> Wolfgang Lux wrote:
>>> 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.
>> 
>> I had a call with Gregory yesterday.. since this is a delciate subject I 
>> made a branch with a proposed initial change (as I have other controls 
>> failing, it will not be the conly class affected either)
>> 
>> BE-64-Fixes
>> 
>> What do you think?
> 
> I think that introducing a new archive format to address the issue with the 
> _highlightsByMask and _altStateMask attributes is a bit over the top. Either 
> decoding the attributes as NSUInteger values as Fred mentioned or decoding 
> them as unsigned int into a temporary variable and then copying the values 
> from those temporary variable into the respective attribute would do. BTW, I 
> don't consider the latter a hack. It's a perfectly sane solution for dealing 
> with backward compatible archives.
> 


I just had a chance for a quick look.
It sounds like the problem is he code 

      [aCoder encodeValueOfObjCType: @encode(unsigned int)
              at: &_highlightsByMask];

where _highlightsByMask is actually NSInteger (signed 64bit)

If you are on a big endian machine,  that would presumably encode the upper 
32bits of the value ... which are probably all zero ... so the data never gets 
into the archive.

So I agree, the bugfix would be to copy _highlightsByMask (lower 32bits) into a 
32bit unsigned integer value first

uint32_t tmp = (uint32_t) _highlightsByMask
[aCoder encodeValueOfObjCType: @encode(unsigned int) at: &tmp];

So the correct value is stored in the archive.

A similar change would be needed to decode into a uint32_t and then copy that 
into place.